Attila Lendvai <att...@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
