Re: Files different for me

From: Jay Soffian <jaysoffian@gmail.com>
Date: Feb 25, 2009, 19:16 UTC
Message-ID: <76718490902251116l12e7d3c5jb42657cb0432ae40@mail.gmail.com>
In-Reply-To: <7v4oyi2vvf.fsf@gitster.siamese.dyndns.org>

On Wed, Feb 25, 2009 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 23 quoted lines

> The handling of a case where a pull decides to go ahead (because it does
> not have to touch the Makefile you have your codename updates in) but does
> not complete with real conflicts, is not as graceful as the other two
> cases (merge refusing to run at all without touching anything, or merge
> completes cleanly and makes a commit).
>
> You will be left with:
>
>  - Paths that have local changes (index matches HEAD but work tree does
>   not match the index --- like your Makefile);
>
>  - Paths cleanly merged (index and HEAD are different but work tree
>   already matches the index);
>
>  - Unmerged paths (index has higher stage entries with <<</===/>>> files
>   in the work tree);
>
> You, I and experienced users know what to do.  Deal *only* with the last
> kind, mark them with "git add" after you are done with each of them, and
> make sure you do not say "-a" when committing the result, to exclude the
> first kind from the merge result.
>
> I've been wondering if we can make this safer for others.

Have pull detect this case and stash if so, with a message to the user to pop the stash after they have committed the merge results? Or would it make more sense to do it in merge? Maybe a pre-merge hook?

j.