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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 7, 2007, 11:05 UTC
Message-ID: <Pine.LNX.4.64.0705071301230.4167@racer.site>
In-Reply-To: <vpqd51duklo.fsf@bauges.imag.fr>

Hi,

On Mon, 7 May 2007, Matthieu Moy wrote:

Show 8 quoted lines

> 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