Why git-merge-resolve in git-am?

Why git-merge-resolve in git-am?

[Shawn Pearce]

Why does git-am use git-merge-resolve while git-rebase -m uses
git-merge-recursive?

Can we just change git-am to use git-merge-recursive instead?
For one thing its faster, for another it supports the GITHEAD_*
feature for naming the hunks in a conflict.

-- 
Shawn.

Re: Why git-merge-resolve in git-am?

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> Why does git-am use git-merge-resolve while git-rebase -m uses
> git-merge-recursive?

The use of merge-resolve by am predates merge-resolve became
usable by at least six weeks, and longer before merge-resolve
became really stable for about an extra month after.

Even after it stabilized merge-recursive was way slower than
merge-resove until it was rewritten in C for another nine
months.

Re: Why git-merge-resolve in git-am?

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > Why does git-am use git-merge-resolve while git-rebase -m uses
> > git-merge-recursive?
> 
> The use of merge-resolve by am predates merge-resolve became
> usable by at least six weeks, and longer before merge-resolve
> became really stable for about an extra month after.
> 
> Even after it stabilized merge-recursive was way slower than
> merge-resove until it was rewritten in C for another nine
> months.

Good reasons, but all are strictly historical.  So there's actually
no technical reason we can't use merge-recursive here in git-am.

Basically I'm trying to improve the merge conflict hunks in
`git-am -3`.  merge-recursive now recognizes GITHEAD_* but
merge-one-file doesn't (and can't).  Switching to merge-recursive
and setting GITHEAD_* would get that case fixed in git-rebase
without -m.

-- 
Shawn.

Re: Why git-merge-resolve in git-am?

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> Good reasons, but all are strictly historical.  So there's actually
> no technical reason we can't use merge-recursive here in git-am.

A very early version of recursive was unusable (it did not pay
attention to the merge base the caller gave it and tried to
always compute it by itself), but that was fixed sometime later.

I do not recall offhand C version still has that fix (I think it
does but you should double check); as long ias it honors the
merge base the caller computed, it should be Ok to replace
resolve with recursive.  Go wild.

Re: Why git-merge-resolve in git-am?

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > Good reasons, but all are strictly historical.  So there's actually
> > no technical reason we can't use merge-recursive here in git-am.
> 
> A very early version of recursive was unusable (it did not pay
> attention to the merge base the caller gave it and tried to
> always compute it by itself), but that was fixed sometime later.
> 
> I do not recall offhand C version still has that fix (I think it
> does but you should double check); as long ias it honors the
> merge base the caller computed, it should be Ok to replace
> resolve with recursive.  Go wild.

I checked.  It does use the merge base supplied by the caller,
but only if the caller supplies only one merge base.  Otherwise it
computes its own.

This isn't a problem for git-am as we only supply one merge base.
What was a problem was git-am supplies trees, not commits, and the
code internally uses commits.  I fixed that in patch 9/11 'Allow
merging bare trees' in my recent series.

-- 
Shawn.