Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757492AbcCRPrH (ORCPT ); Fri, 18 Mar 2016 11:47:07 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:36470 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410AbcCRPrE (ORCPT ); Fri, 18 Mar 2016 11:47:04 -0400 MIME-Version: 1.0 In-Reply-To: References: <56EB9B0C.4050507@nvidia.com> Date: Fri, 18 Mar 2016 08:47:02 -0700 X-Google-Sender-Auth: T6q1Jt0bn3GtYrvyEhpw9USwQtg Message-ID: Subject: Re: [GIT PULL] GPIO bulk changes for kernel v4.6 From: Linus Torvalds To: Johannes Schindelin Cc: Laxman Dewangan , Junio C Hamano , Linus Walleij , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Git Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1441 Lines: 35 On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin 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