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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 7 May 2007, Matthieu Moy wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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