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

From: Nicolas Pitre <nico@cam.org>
Date: Dec 15, 2006, 04:07 UTC
Message-ID: <Pine.LNX.4.64.0612141343200.18171@xanadu.home>
In-Reply-To: <7v7iwu93rv.fsf@assigned-by-dhcp.cox.net>

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

Show 13 quoted lines

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