Re: [FAQ?] Rationale for git's way to manage the index

Hi,

On Mon, 7 May 2007, Matthieu Moy wrote:

Johannes Schindelin [off-list ref] writes:

quoted

Just another reason to hate CVS. Because it trained people to do that. If 
it was not for the training by CVS, I would have strongly opposed to the 
introduction of the "-m" switch to commit. It _encourages_ bad commit 
messages.

Well, this really depends on the use-case, size of commit, ...

Okay, so I use "-m" myself sometimes.

I often use a version control system for very low importance stuff. I 
don't want to type a 3-lines long message to describe a 2-lines long 
change in my ~/.emacs.el for example.

IIRC our record is 90+ lines of commit message for a one-line change.

I also work with people using (sorry) svn to work collaboratively, but 
they don't even provide a log message: the version control system here 
is just a replacement for unison/NFS/whatever other way to have people 
edit files from different machines.

I positively _hate_ empty commit messages. There is _always_ something to 
be said about the intent of the change, that has no place in the code.

For sure, in a context where code quality and review is important, -m 
"xxx" isn't the way (except if you prefer your shell's line editor to 
your actual editor).

I also find it very useful for my own pleasure when reviewing some logs. I 
track config files, small scripts, documents, etc. with Git, and I found 
myself looking for something in _all_ of them. The commit messages helped.

Commit messages, BTW, are somewhat of an artform. You cannot imagine how 
slow I am writing them, because they should be helpful not only for the 
reviewer, but also for the casual git-blame user, who wants to find out 
the rationale of a change.

Ciao,
Dscho