Re: splitting up and sorting commits?

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On mer., 02 nov. 2022 at 00:05, Csepp <raingloom@riseup.net> wrote:

> I'm working on a fairly sizeable MirageOS branch, just getting the
> hello-world kernel running involved adding about 40 packages.  Very
> often I run into a scenario where an imported package needs some other
> package to compile, and then that needs another, and then that another,
> and so on and so on, so by the time I can commit the first I have a
> plethora of new packages that should in theory all get their own
> commits.
> There are two problems with this:
> * Splitting up the commit is a pain, even with git add --patch, because
> hand editing the diff sucks and splitting does not work, possibly due to
> there not being enough space between defines for git's taste.
> * 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.
>
> How should one solve this?  I already spent way too much time on a
> script that I foolishly thought would be able to automatically sort
> commits based on their dependencies, but now I'm throwing in the towel,
> it's not getting anywhere.

Well, I do not know if I am answering the questions. :-)

Maybe what you are looking for is ./etc/committer.scm which tries to
split the complete change to small chunks and commit them.

Recently, I was updating Julia packages and I hit something similar.
Well, I have started with “./pre-inst-env guix refresh -u -m
julia-packages.scm” and then “./pre-inst-env ./etc/commiter.scm” which
leads to ~140 commits.  Next, I add the missing packages (committing
them individually) such that the final state just builds and I fix some
tests etc.

Last, I rebase all and edit the history.  Using Magit and Emacs, it is
really straightforward.  The main issue with large change is on one hand
to have that each atomic commit builds fine and on the other hand keep
each commit as atomic as possible.  Well, from my point of view, it is
tradeoff – personally, I am ready to have some commits that do not build
and keep them atomic.

Well, I have also spent too much time trying to find the correct order.
I also tried to an ugly script using the DAG to sort the packages but
then some updates require other specific version… and it is nearly
impossible to satisfy all the constraints.


Cheers,
simon