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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 20, 2007, 19:55 UTC
Message-ID: <7vy7g6rnev.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20070820180809.GA8542@efreet.light.src>

Jan Hudec <bulb@ucw.cz> writes:

Show 6 quoted lines

>> 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.