Re: [PATCH] Document what the stage numbers in the :$n:path syntax mean.

Jan Hudec [off-list ref] writes:

quoted

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.