Re: [PATCH] make commit message a little more consistent and conforting

[Nicolas Pitre <nico@cam.org>]

On Thu, 14 Dec 2006, Shawn Pearce wrote:

> Nicolas Pitre <nico@cam.org> wrote:
> > It is nicer to let the user know when a commit succeeded all the time, 
> > not only the first time.  Also the commit sha1 is much more useful than 
> > the tree sha1 in this case.
> 
> I agree the commit sha1 is more useful than the tree sha1, but I'm
> not really sure its useful to show the commit sha1 post commit.

It is useful, even if it is not essential.

Since I believe it is a good thing to display _something_ by default 
(and not only with -v as suggested -- please see the reasoning I posted 
yesterday as to what should have some output and what shouldn't), it 
doesn't hurt to display the commit sha1 as well.

First it has the very desirable side effect of making the user slightly 
aware of how git identifies things.  From the first commit a new user 
will notice that git doesn't use any incremental version number but a 
unique identifier that has nothing to do with sequence.  It is not 
expected that people will start _using_ the information printed, but it 
will at least give a feel of how git works.  And it is not like if the 
whole thing took multiple lines to be displayed.

Next it _might_ be used by people.  The fact that it is there might turn 
to be useful.  It is useful in the context of Documentation/tutorial-2.txt
for one where the notion of objects and their relationship is explained 
based on the least amount of steps possible.

So in short I do think there should be something shown after a 
successful commit, and including the commit sha1 doesn't hurt.

> If you want to show something the diffstat like what git merge does
> is better.
> 
> For one thing it confirms that git accepted the changes.  For another
> it shows you *which* changes it accepted.  Plus it responds just
> like git-merge or git-pull does.

I disagree.  My patch does confirm that git accepted the change with 
only one line.  As to which changes were accepted I think that when you 
do the commit you certainly have a pretty good idea already of what is 
going to be committed (you modified/added/removed files yourself, and by 
default git-commit provides you with a summary in the text editor for 
the commit message).

On Fri, 15 Dec 2006, Shawn Pearce wrote:

> Andreas Ericsson <ae@op5.se> wrote:
> > diffstats can be huge though. I'd rather have those only with -v option.
> 
> But they are on by default for pull/merge, and disabled by -n.
> 
> They are on to tell you what you just got during the pull/merge.

The pull/merge case is different.  You are most likely to not know in 
advance what the overall changes will be.  Of course you're supposed to 
know what you're pulling, but unlikely to know about the detail since 
what you merge is remote to your current working tree by definition, and 
even if you happen to be the one who did the changes in the other 
branch/repo, it is certainly not as fresh in your mind than the changes 
you did prior a commit.

And it is true that diffstat can be quite large.  I wouldn't mind the 
diffstat to be added to the commit message summary in the text editor 
though.  And displaying it when -v is used makes also a lot of sense.  
But not by default please.