Andreas Enge <andr...@enge.fr> writes:
> Hello, > > Am Wed, Nov 02, 2022 at 12:05:54AM +0000 schrieb Csepp: >> * It is very easy for package to get added before their dependencies, so >> even though by the end of the commit chain everything builds perfectly >> fine, there are intermediate commits that can't be tested on their own. > > maybe it can be handled by a different workflow? I usually use the git stash > to perform a depth first traversal of the dependency graph like so: > - Add package A. Try to build it and see that it needs dependency B. > "git stash". > - Add package B *instead*. Try to build it... > (da capo ad libitum) > - "git commit" with package B. > - "git stash pop". Try to build package A etc. > - "git commit" with package A. > > The only drawback is that B and A are often defined next to each other, > which creates a spurious merge conflict during "git stash pop", but that > is easy to solve and requires an additional "git stash drop" in the end. > > Sometimes I even give up on package A in the end, but then at least B > has been added to Guix :) > > Andreas I tried that, the merge conflicts drove me nuts. And juggling the stash stack was a nightmare. Instead I ended up committing each package individually without caring about dependencies, then doing an interactive rebase where every command was edit. If I saw warnings about undefined variables I ran git rebase --edit-todo **without** magit, because it made simple textual edits needlessly hard (this is why I use Kakoune and Emacs side by side), opened .git/rebase-merge/done, cut the last line, pasted it in todo after its dependency, ran git reset --hard "HEAD^" **ONLY** if HEAD was actually that commit, if it was not yet committed because there was a merge conflict, I ran git rebase --skip. Yep, figuring out when to reset and when to skip took a few tries. :)
