Jan Hudec <bulb@xxxxxx> writes: >> These days, all the merge strategies and other non-merge >> programs such as "git am" that can record conflicts as >> multi-stage index entries consistently use stage #2 as our >> version, and stages #2 and #3 are not equals anymore. > > Pardon me? In what are they not equal? The version left in the worktree always corresponds to stage #2. There is no way to say "please use stage #2 for their version and use stage #3 for our version" (that is not necessary, so don't take this as if I am complaining about a lack of feature). "git-read-tree -m" knows that stage #2 corresopnds to the index and the worktree and performs up-to-date check on them to make sure you do not lose local changes. Merge parent order does not matter --- they are more equal than stages between #2 and #3. But that's not what we are discussing here. In some minor corners merge parents are not exactly equal -- history simplification and other places that wants to pick one parent iterates from the first to the last parent and pick the first one, so strictly speaking earlier parents have a slight edge over later ones. - 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
