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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2008, 04:07 UTC
Message-ID: <7vzlugf3la.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vzluggp0q.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

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