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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  Hi,

On Mon, May 07, 2007 at 01:05:44PM CEST, Johannes Schindelin wrote:
> On Mon, 7 May 2007, Matthieu Moy wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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'm maybe somewhat standing out of the crowd, but I sometimes use -m
for *very* long commit messages - just using separate -m parameters for
paragraphs and writing on; I tend to find it much more natural than
spawning an editor. Only when I find later that I've made an ugly typo
in the middle of 250-characters commandline or I figure out that I
should add some figure to the message, I throw in -e at the end and add
the final touches.

..snip..
> 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.

  But I agree that commit messages are somewhat of an artform, and
just finding a good headline can be quite difficult sometime. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux