From: Junio C Hamano Date: Mon, 20 Aug 2007 19:55:36 GMT Subject: Re: [PATCH] Document what the stage numbers in the :$n:path syntax mean. Message-ID: <7vy7g6rnev.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20070820180809.GA8542@efreet.light.src> Jan Hudec 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.