Messages in this thread | | | Date | Fri, 18 Mar 2016 10:01:25 -0700 | Subject | Re: [GIT PULL] GPIO bulk changes for kernel v4.6 | From | Linus Torvalds <> |
| |
On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano <gitster@pobox.com> wrote: > >> I don't think the original "resolve" did it, for example. You can't do >> a three-way merge without a base. > > Yes, and that continues to this day:
Yeah, "octopus" also refuses it cleanly:
common=$(git merge-base --all $SHA1 $MRC) || die "Unable to find common commit with $pretty_name"
The code in the recursive merge that allows this to happen is this:
if (merged_common_ancestors == NULL) { /* if there is no common ancestor, use an empty tree */ struct tree *tree;
tree = lookup_tree(EMPTY_TREE_SHA1_BIN); merged_common_ancestors = make_virtual_commit(tree, "ancestor"); }
so the "no common ancestors" is just considered to be an empty merge base.
And I do think that's right, and I think it's clever, and it goes back to 2006:
934d9a24078e merge-recur: if there is no common ancestor, fake empty one
but I think there should be an option there.
> This is a tangent but I wonder if we should say why we refuse to > the standard error before calling these two "exit"s.
As mentioned, Octopus does.
That said, there's probably no reason to ever use the old three-way merge, so I'm not even sure it's worth fixing the old git-merge-resolve.
Linus
| |