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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <junkio@xxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]