Jeff King [off-list ref] 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.
On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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