Subject: Re: [PATCH 3/4] git-commit: Refactor creation of log message.

From: Junio C Hamano <[email-masked]>
Date: Mon, 04 Feb 2008 20:07:45 -0800

Junio C Hamano <[email-masked]> writes:

> I suspect Dscho was worried about the case where he says "git
> commit", types message and then write-tree finds out that the
> index is still unmerged and the tree cannot be written out.
>
> And I'd be majorly annoyed if the "slight disadvange" was about
> that.
>
>>         discard_cache();
>>         read_cache_from(index_file);
>>         if (!active_cache_tree)
>>                 active_cache_tree = cache_tree();
>>         if (cache_tree_update(active_cache_tree,
>>                               active_cache, active_nr, 0, 0) < 0) {
>>                 rollback_index_files();
>>                 die("Error building trees");
>>         }
>
> I think this _could_ error out if your index is unmerged.

I just tried.  This would annoy me.

It is common to do something like this:

	$ git cherry-pick -n somethingelse
        $ git add this-and-that-path.c
        $ git commit

to get partial changes from somethingelse for paths you only
care about, and commit the result.  And you often get conflicts
to paths that do not matter (think of backporting trivial part
of fixes).  You need to reset the paths you do not care about
that conflicted, but you can forget that before running "git
commit".

With our "git commit", you first get "foo: unmerged" and you do
not see the editor.  With this change, you edit the message and
then see "foo: ummerged".