From: zimoun <zimon.toutoune@gmail.com>
To: Florian <florhizome@posteo.net>, 60013@debbugs.gnu.org
Subject: [bug#60013] [PATCH 1/3] gnu: Add libmodule
Date: Fri, 30 Dec 2022 13:45:30 +0100 [thread overview]
Message-ID: <87k029kql1.fsf@gmail.com> (raw)
In-Reply-To: <871qounifm.fsf@posteo.net>
Hi,
On Tue, 20 Dec 2022 at 16:33, Florian <florhizome@posteo.net> wrote:
> Creating a branch, yes, but continuously rebasing them all and recompiling before
> working on each single commission: yes (building guix is pretty time
> intensive). This is where I think guix lacks a proper CI/CD. That contributors
> even have to check if a patch applies, if it builds and run guix lint
> seems paradox to me, especially with the capacity problems that already exist
> when accepting submissions.
Are you aware about <https://qa.guix.gnu.org/patches>?
And for what it is worth, your submission [1] fails with the Guix CI/CD.
Probably because your patches do not apply correctly.
1: <https://qa.guix.gnu.org/issue/60013>
What I was suggesting is not to rebase and not to rebuild but instead to
cherry-pick and then correctly format patches. Please note that this
comment applies equally for any workflow – even for some PR workflow à
la Git{Hub,Lab}.
> I think the problem you have comes from multiple patches of mine being in
> wm.scm which has also made rebasing more complicated. Git really seems
> to struggle when patches have hunks in one file that might touch each other,
> that I haven't really understood how to avoid. but I can check
> one more time. Maybe we could have a look at how the patch is failing?
As pointed in [1], the patch just does not apply,
--8<---------------cut here---------------start------------->8---
error: patch failed: gnu/packages/wm.scm:102
error: gnu/packages/wm.scm: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Applying: gnu: Add clightd
Patch failed at 0001 gnu: Add clightd
--8<---------------cut here---------------end--------------->8---
because of gnu/packages/wm.scm:102. From my understanding, it is not
about rebasing, it is about which state of the file the diff must apply
against.
What I was suggesting is to extract these 3 patches using cherry-pick
and so format the patches against a clean origin/master. For instance,
--8<---------------cut here---------------start------------->8---
git checkout -d example
git reset --soft 0ce1f82e5aaac951b21d579eb46bf75cfe6713c0
git cherry-pick 5ad571d5a145a7a33ec9241bf75f25cf4864e629
git cherry-pick <commit-hash-adding-clightd>
git cherry-pick <commit-hash-adding-clight>
git format-patch -3 --cover-letter --base=0ce1f82e5aaac951b21d579eb46bf75cfe6713c0
git checkout master
git branch -D example
--8<---------------cut here---------------end--------------->8---
where 0ce1f82e5aaac951b21d579eb46bf75cfe6713c0 is a clean
’origin/master’ when you created this patch set. And where
5ad571d5a145a7a33ec9241bf75f25cf4864e629 is the commit adding libmodule.
It changes nothing for you, IMHO, and it helps for having patches which
correctly apply; although you still have other unreleated patches.
1: <https://yhetil.org/guix/86pmckdhts.fsf@gmail.com>
Cheers,
simon
prev parent reply other threads:[~2022-12-30 15:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-12 16:53 [bug#60013] [PATCH] gnu: Add clight Florian
2022-12-12 19:16 ` zimoun
2022-12-12 20:51 ` Tobias Geerinckx-Rice via Guix-patches via
2022-12-12 20:31 ` [bug#60013] [PATCH 1/3] gnu: Add libmodule florhizome
2022-12-12 20:31 ` [bug#60013] [PATCH 2/3] gnu: Add clightd florhizome
2022-12-12 21:53 ` ( via Guix-patches via
2022-12-12 20:31 ` [bug#60013] [PATCH 3/3] gnu: Add clight florhizome
2022-12-12 21:57 ` ( via Guix-patches via
2022-12-12 21:00 ` [bug#60013] [PATCH 1/3] gnu: Add libmodule ( via Guix-patches via
2022-12-12 23:48 ` zimoun
2022-12-13 11:51 ` Florian
2022-12-15 11:31 ` zimoun
2022-12-20 16:33 ` Florian
2022-12-21 11:22 ` ( via Guix-patches via
2022-12-30 12:45 ` zimoun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k029kql1.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=60013@debbugs.gnu.org \
--cc=florhizome@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).