Re: git-name-rev off-by-one bug

From: Junio C Hamano <junkio@cox.net>
Date: Nov 29, 2005, 23:14 UTC
Message-ID: <7vsltf6o8f.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051129214055.8689.qmail@science.horizon.com>

linux@horizon.com writes:

> This seems odd to me.  There's an alternate implementation that
> I described that makes a lot more sense to me, based on my current
> state of knowledge.  Can someone explain why my idea is silly?

It is not silly.  Actually we have "been there, done that".

We used to leave the higher stages around in the index after automerge failure. Note that you would not just have stage2 in such a case. stage1 keeps the common ancestor, stage2 has what you started with, and stage3 holds the version from other branch. diff-stages can be used to diff between these stages. We _could_ have added feature to either diff-stages or diff-files to compare between stageN and working tree.

However, this turned out to be not so convenient as we wished initially. What you would do after inspecting diffs between stage1 and stage3, between stage2 and stage3 and between stage1 and stage2 typically ends up doing what "merge" have tried (and failed) manually anyway, and being able to find the conflict markers by simply running "git diff" was just as good, except that we risk getting still-unresolved files checked in if the user is not careful.

If you want to be clever about an automated merge, you could write a new merge strategy to take the three trees and produce a better automerge result. That is what Fredrik has done in his git-merge-recursive (now default). Or you could "improve" git-merge-one-file to take three blob object names and leave file~1 file~2 file~3 in the working tree, instead of (or in addition to) leaving a "merge" result with conflict markers, to give the user ready access to the version from each stage.