Re: Should commits rather be buildable or small

[Ricardo Wurmus <rekado@elephly.net>]

Attila Lendvai <attila@lendvai.name> writes:

>> I guess "required" here means that in some cases Guix's policy is to
>> prefer small commits over buildable commits (with the previous
>> definition). I at least don't see any technical reasons why it would be
>> required. The question then becomes whether that policy applies in this
>> case.
>
>
> FWIW, this commit policy has always bothered me as a newcomer to
> Guix. pretty much everywhere else it's a major offence against your
> colleagues to commit something that breaks the build in any way.

In the last few months I’ve repeatedly seen assertions in a similar
style as this one.  They always genuinely surprise me, and it’s probably
not just because I’m oblivious and out of touch.

Also in Guix it is not okay to commit intermediate things that break
stuff.

Commits should, however, also tell a reviewable story and not be a big
blob of thousands of lines of non-trivial changes.  (The one exception
has always been fixes of repeated typos, but this is not what this
discussion is about.)

For what it’s worth: when I do bulk R upgrades I generally have one
commit per package upgrade, because it’s easy to review in a git log in
the future and easy to revert individual changes with fine grain access.
Of course I group upgrades that depend on one another (e.g. r-arrow
together with apache-arrow and the inheriting python-arrow).

-- 
Ricardo