From: Jay Soffian Date: Wed, 25 Feb 2009 19:16:25 GMT Subject: Re: Files different for me 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 wrote: > 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.