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

From: linux@horizon.com <linux@horizon.com>
Date: Nov 30, 2005, 00:15 UTC
Message-ID: <20051130001503.28498.qmail@science.horizon.com>
In-Reply-To: <7vsltf6o8f.fsf@assigned-by-dhcp.cox.net>

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

Um, okay, but I don't see why you changed...

Show 7 quoted lines

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

Yes, exactly.  This is what I expected.

Show 8 quoted lines

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

You seem to be saying that producing a merge with conflict markers is what you (almost) always want, so it's the default. No objections.

But why collapse the index and only keep stage2? Why not leave all stages in the index *and* the merge-with-conflict-markers in the working directory?

They you could, for example, try alternate single-file merge algorithms on the conflict, or regenerate the conflict markers if you wanted. By keeping all of the source material around until the user has decided on a resolution, you achieve maximal flexibility.

This is no more effort for the user to use in the common case (edit the conflicts and git-update-index), but lets you try various things in the working directory and eaily back out of them. ("git-merge-index -s manual -a" would regenerate all of the conflict markers.) And it prevents a checkin until the matter has been resolved.

I'm wondering if this isn't a philosophical issue. One side says that, since all automated merging is complete, the stages should be collapsed. To me, it makes more sense to leave out the adjective "automated" and consider the merge to be incomplete; we're just putting the user in the loop when software fails.