Re: What's in git.git (stable)

[Nicolas Pitre <nico@cam.org>]

On Thu, 14 Dec 2006, Junio C Hamano wrote:

> Andy Parkins <andyparkins@gmail.com> 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.