Aborting "git commit --interactive" discards updates to index (was: Re: [ANNOUNCE] Git 1.7.6)

On 27 June 2011 17:59, Junio C Hamano [off-list ref] wrote:

The latest feature release Git 1.7.6 is available at the usual
places:

 http://www.kernel.org/pub/software/scm/git/

[snip]

 * Aborting "git commit --interactive" discards updates to the index
  made during the interactive session.

Hi, I am wondering why this change was made?

I can sort of understand if people do CTL-C during an interactive
commit that throwing the results away might be useful (although I
don't see why personally), but what I don't understand at all is why
it happens when the "add --interactive" is completed properly, but the
user decided not to actually commit. For me and a number of colleagues
the normal reason we exit the commit part (that is exit the editor
without modifying the commit message) is because we realize we forgot
something, such as adding a new file, and want to exit out and re-add
it. I am writing this after spending about 45 minutes showing a
colleague how to use git commit --interactive, when we realized that
we had forgotten to add a file. Needless to say he wasn't too happy
about losing 45 minutes work and having to redo it.

The new behavior potentially means that a lot of work (such as via the
'e' option) is instantly discarded. I don't understand why this is
perceived to be sensible behavior -- I thought the default policy for
git would be to not lose work!

I would really like an git config option to revert to the previous
behavior of not throwing away what I staged, or even better have git
commit --interactive ask me what I want to do, after all, it is an
interactive process so it seems reasonable it asks before it does
something like throw away work.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"