On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > On Fri, 18 Mar 2016, Linus Torvalds wrote: > >> I thought git didn't merge two branches that have no common base by >> default, but it seems it will happily do so. > > What happened to "The coolest merge EVER!"? > > http://thread.gmane.org/gmane.comp.version-control.git/5126/ I'm not complaining about multi-root capability in general - it's still cool. In the kernel, we have aef8755711a2 ("Merge Btrfs into fs/btrfs") that does something slightly similar. It's literally just the fact that "git merge" does it with no extra flags or checks. I'd like people to have to be aware of what they are doing when they merge two different projects, not do it by mistake. So making it conditional on a flag like "--no-common-root" is what I'd look for. Or just make it about the merge stategy. For example, "subtree" makes sense exactly for merging one project into a subdirectory of another. But the default merge shouldn't do it. I don't think the original "resolve" did it, for example. You can't do a three-way merge without a base. Note how that above "coolest merge" definitely wasn't done by just "git merge gitk". I had to play around with the git internals. Now, it shouldn't be _that_ hard, but at the same time it really shouldn't be as easy as "I didn't know, so I merged two independent projects". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html