Re: Should commits rather be buildable or small

[Ricardo Wurmus <rekado@elephly.net>]

Attila Lendvai <attila@lendvai.name> writes:

> i myself also had headaches multiple times when i fixed something that
> needed to touch several different packages, and they would only work
> when applied in one transaction:
>
> how many debbugs issues? multiple issues and record the dependencies?
> little gain for much more effort on both sides... but if one issue,
> then what should be the name of the debbugs issue? etc...

We often have just one debbugs issue per transaction, i.e. multiple
patches that all belong to the same issue.  The free form cover letter
should describe what the relation between the patches is.

This can be done for dependencies (e.g. an R package and all the
unpackaged things it needs) or for a feature with several related but
atomically recorded changes.

A misconception I read earlier is that there’s a desire to have one
commit per touched file, but that’s certainly not true.  Atomicity
doesn’t care about file boundaries, and we don’t care about them either.
Commits should tell a story and often it is easier to tell it by making
consecutive independent changes.

-- 
Ricardo