On Thu, Jan 03, 2013 at 12:34:27PM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > Or are you suggesting that the three-way case should always be protected > > by checking that there are no unmerged entries before we start it? That > > seems sane to me, but I haven't confirmed that that is the case. > > I think the normal (and hopefully only) "-m -u O A B" use case of > threeway is the bog-standard "git merge", which requires even more: > your index must exactly match HEAD, even though you are allowed to > have local changes in the working tree. > > That requirement is not likely to change, as cleanly merged paths > are automatically added to the index, so "diff --cached" should show > only the changes from cleanly merged part, while "diff" should show > paths that still needs user's help. > > If we allowed local modification to the index (let alone conflicted > entries in it) before the merge begins, the users would not be able > to tell which paths are in what state after a half-merge stops and > asks for help. Updated paths may not have anything to do with the > merge (i.e. earlier "git add" before the merge started), conflicting > paths may not have anything to do with the merge (i.e. leftover > conflicts before the merge started).
Oh, I agree it's insane to try to carry through unmerged entries. I'm just concerned that not all code paths are careful enough to check. They probably are, though, as a null sha1 in your index would be the least of your worries, and somebody would have noticed in the last 7 years. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
