On Thu, 14 Dec 2006, Shawn Pearce wrote: > Nicolas Pitre <nico@xxxxxxx> 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@xxxxxx> 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. Nicolas - 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