Re: splitting up and sorting commits?

[Csepp <raingloom@riseup.net>]

Andreas Enge <andreas@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. :)