On Wed, Feb 25, 2009 at 1:51 PM, Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
