# Why git-merge-resolve in git-am? 5 messages from 2006-12-28 to 2006-12-28. Participants: Shawn Pearce, Junio C Hamano. Thread: https://gitlist.dev/t/6136 ## Shawn Pearce, 2006-12-28 01:45 Subject: Why git-merge-resolve in git-am? Message-ID: <20061228014525.GC16612@spearce.org> URL: https://gitlist.dev/e/20061228014525.GC16612%40spearce.org ``` 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. ``` ## Junio C Hamano, 2006-12-28 02:11 Subject: Re: Why git-merge-resolve in git-am? Message-ID: <7vr6uk3h2p.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr6uk3h2p.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061228014525.GC16612@spearce.org> ``` Shawn Pearce 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. ``` ## Shawn Pearce, 2006-12-28 02:20 Subject: Re: Why git-merge-resolve in git-am? Message-ID: <20061228022038.GE16612@spearce.org> URL: https://gitlist.dev/e/20061228022038.GE16612%40spearce.org In-Reply-To: <7vr6uk3h2p.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Shawn Pearce 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. ``` ## Junio C Hamano, 2006-12-28 02:28 Subject: Re: Why git-merge-resolve in git-am? Message-ID: <7virfw3gb2.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7virfw3gb2.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061228022038.GE16612@spearce.org> ``` Shawn Pearce 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. ``` ## Shawn Pearce, 2006-12-28 07:48 Subject: Re: Why git-merge-resolve in git-am? Message-ID: <20061228074857.GC17304@spearce.org> URL: https://gitlist.dev/e/20061228074857.GC17304%40spearce.org In-Reply-To: <7virfw3gb2.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Shawn Pearce 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. ```