Santiago Vila wrote:
> btw: I'm curious about the "two patches + one more to fix the first two".
> It is not the usual thing to squash patches before distributing them,
> particularly when one of them fixes things in the others?
As long as the developer has not pushed their patches, when they find a
problem, yes typically they will use "git commit --amend" or "git rebase -i"
with 'squash', in order to tweak the patches or commit messages.
But quite often we tend to think "my patch is good, let me push it before I
turn to other things" and realize a problem later. Once pushed, no --amend
is possible. While it is possible to reduce the frequency of such events,
it comes with a cost:
- The developer can think "let me push it the next morning". But since
pushing is accompanied with sending out a mail, it is cumbersome to
delay it.
- We could have more than one development branch in Gnulib. But then
someone would have to spend time evaluating and propagating commits
from the "nearly-master" branch to the "master" branch.
- While some people use "topic" branches, they come with hassles of
their own, because each time you switch to a different branch during
development, you have to do a "make distclean" and re-configure (or
even re-bootstrap).
In summary: Mistakes happen. And as long as they are discovered and fixed
quickly, that's fine. Things would be different in a project with 100
concurrent contributors, but Gnulib is not a project of that size.
Bruno
