On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > So I think we need to update twoway_merge to recognize unmerged entries, > > which gives us two options: > > > > 1. Reject the merge. > > > > 2. Throw away the current unmerged entry in favor of the "new" entry > > (when old and new are the same, of course; otherwise we would > > reject). > > > > I think (2) is the right thing. > > As "--reset" in "read-tree --reset -u A B" is a way to say "we know > we are based on A and we want to go to B no matter what", I agree we > should not reject the merge. > > With -m instead of --reset, I am not sure what the right semantics > should be, though. Good point; I was just thinking about the --reset case. With "-m", though, we could in theory carry over the unmerged entries (again, assuming that "old" and "new" are the same; otherwise it is an obvious reject). But those entries would be confused with any new unmerged entries we create. It seems we already protect against this, though: "read-tree -m" will not run at all if you have unmerged entries. Likewise, "checkout" seems to have similar protections. So I think it may be a non-issue. -Peff -- 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