Re: Merge with staged and unstaged changes

From: Edward Thomson <ethomson@microsoft.com>
Date: Feb 20, 2013, 21:46 UTC
Message-ID: <A54CE3E330039942B33B670D971F85740396C4F8@TK5EX14MBXC254.redmond.corp.microsoft.com>
In-Reply-To: <7vobfeybwt.fsf@alter.siamese.dyndns.org>

On 2/20/13 2:21 PM, "Junio C Hamano" <gitster@pobox.com> wrote:

Show 5 quoted lines

>Both are very much on purpose. The integrator may have seen the
>patch on the list, ran "git apply [--index]" on it to contemplate on
>it, and before commiting the result, saw a pull request for a branch
>that contains the change.  The above two allow the pull from such a
>state to succeed without losing any information.

>I think we have a similar table in Documentation/technical area that
>explains these things, by the way.

I believe you are referring to trivial-merge.txt which has been exceptionally helpful in understanding "what" unpack trees does. I appreciate this detailed explanation in providing the "why".

I also appreciate your explanation of the affect of the workdir, and that makes sense. I would have expected that the default was to presume the workdir files were existent, rather than the other way around, but we can agree that is an implementation detail.

My biggest concern, of course, was having the unstaged files in my workdir overwritten or deleted.

Thanks again-

-ed