On Thu, 14 Dec 2006, Junio C Hamano wrote: > Andy Parkins <andyparkins@xxxxxxxxx> writes: > > > $ git commit > > Revision XXXXXXXXXXXXXXXXXX successfully added. > > > > I'd actually argue that git-commit is a particular problem because it's too > > fast. You quit editing your commit message and bang, you're back at the > > command line. Then you run git-log to make sure it really was committed. > > You keep repeating that you want to know the object name of the > newly created commit. I would very strongly agree with you that > it would be a fatal UI bug of git-commit if that information > were vital for the end user after making each commit. I think this is not the point. Of course the name of the newly created commit isn't _that_ important. But so is the "Committing initial tree 5220388..." message. And in the commit case, you are left with a blank screen and just a shell prompt after you quit the text editor for the log message, which is a bit worrisome. My initial reflex is not to think "ah it just did what I asked it" but rather "hmmm has it just crashed on me?" Having a single line of feedback when a commit has completed would not be overly verbose and remove that impression of committing into a void I'd think. Note that, as I said in another thread, I'm really not advocating for git-add to do the same. The git-add is a relatively simple and lightweight operation that has not the same impact as a commit has _conceptually_. It doesn't clear the screen for one thing so just returning to the shell prompt (unless -v is used) is plenty sufficient. I'm following up with a patch to implement what I think should be done. 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