Re: [PATCH 06/10] * modules/pselect: Add select, LIBSOCKET.

[Stefano Lattarini]

On Wednesday 06 July 2011, Paul Eggert wrote:
> On 07/06/11 11:48, Stefano Lattarini wrote:
> > If you've noticed a blunder in your
> > ChangeLog *before* pushing, why haven't you amended the commit the
> > blunder occurred into, instead of adding the fix in the following
> > commit?
> 
> Well, partly because I was lazy.  But there's a bigger issue here.
> 
> I sometimes prefer to let people see my mistakes than to polish and
> polish and polish and pretend that I didn't make any.
>
I understand the feeling, and I (partly) agree with it.  But see below.

> Excessive
> polish is common in some fields (mathematics, for example) but it's
> inefficient and sometimes even counterproductive in real-worldish
> engineering endeavors like gnulib.  I often learn from other people's
> mistakes, and I imagine that other people sometimes learn from mine.
>
OK, but here we aren't speaking about a real mistake, only a blunder.
Leaving it around also in the pushed commits only adds confusion IMHO,
without improving the "sense of history" of the repository, nor
allowing other people to learn anything useful from it.

Let me try to explain better what I mean with a concocted example.

Assume you write a new gnulib module, test it on Linux, FreeBSD and
Solaris, and see that it works there.  Good.  Then you commit the module
to your local git repo. Later, you test the module on OpenBSD too, and
see a compile error due to some incompatibilities in the headers (let's
say because OpenBSD doesn't follow POSIX at 100% in one system headers
used by your module).  So you and commit a fix for that problem locally
(referencing the OpenBSD failure in the code comments and in the commit
message).  At this point, you have the choice of merging the two commits
before pushing, so that your code works on OpenBSD "right away"; but I
agree with you that doing so in this case would be excessive polishing,
and that it's better (as in "more clear and more instructive") to let
the world see the "real history" of the module instead.

On the other hand, if, before pushing, you notice that you've referenced
the wrong file in the ChangeLog entry of the first commit, I think the
right choice is to go back and fix that commit before pushing.  Similarly
if you see that you haven't followed the GNU coding conventions in some
places in you module code: you amend the commits before pushing, because
doing the reformatting later would only add noise and confusion.

I hope the above makes sense :-)

Thanks for the patiance,
  Stefano