Re: Proposal for new git Merge Strategy

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Aug 23, 2006, 23:05 UTC
Message-ID: <46a038f90608231605w4d08d59bw42fc84669e16363f@mail.gmail.com>
In-Reply-To: <7vsljngr34.fsf@assigned-by-dhcp.cox.net>

On 8/24/06, Junio C Hamano <junkio@cox.net> wrote:

> Jon Loeliger <jdl@jdl.com> writes:

...

Show 6 quoted lines

> > Any thoughts down this line?  Good idea?  Bad idea?
>
> We had some discussion on this with Catalin in "Unresolved
> issues #3" thread, regarding git-xxdiff (did I ever take it?  I
> liked it for what it does, but I was not sure about its
> odd-man-out-ness) which was proposed by Martin Langhoff.

I've been slack on my reading of the list lately so totally missed out on that thread. I'll go and read it now...

...

> We should be able to make the part that call "merge/diff3" to
> alternatively call xxdiff or its friends (kompare, emerge, pick
> your favorites).  Catalin even showed us a code snippet used in
> StGIT for this in the thread.

I still think that the default initial behaviour git has is right. Most conflicts are trivial, and people can deal with conflict markers just right. It's what we are used to.

Except when it's a mess and it's unclear what goes where and why. That's when git log --merge and my git-xxdiff help. I've also been wondering if I can do gitk --merge easily ;-)

Show 8 quoted lines

> Martin's proposed tool git-xxdiff is meant to be invoked after
> all of the above still left conflict markers.  As Catalin
> pointed out, using "xxdiff -U" to work on a file with conflict
> markers is less powerful than working on three stages directly,
> but on the other hand it can be used as the last stage fixup,
> independent from what git-merge does internally.  In other
> words, it is meant to help solving the same problem but in a
> different part of the workflow.

My implementation doesn't use the 3 stages either, just because I didn't see xxdiff giving any stage a particular meaning. I should rework it to have the 3 stages there, and trust users to read the filename, which should say 'ancestor'.

In terms of the one script or many, if there is concensus on OneScriptToRuleThemAll, I am not that opposed to reworking it to something like

  git-mergehelper --tool xxdiff path/to/file.c

with a big switch statement inside the script :-p What bothers me is that there may be interesting parameters to pass to the invoked tool, and other than having a stupid '--toolopts' passthrough, we are pretty fsck'd.

By having separate git-xxdiff, git-meld, etc the git- scripts would accept all/most of the same params that the tool accepts, therefore feeling "natural" to users of the tool. A definite advantage, IMHO.

{Ugh, my implementation doesn't get that far. But hey, good intentions!}

cheers,

martin