Re: [GIT PULL] GPIO bulk changes for kernel v4.6

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 18, 2016, 15:47 UTC
Message-ID: <CA+55aFwbRVG-5AW+NnMOFZ_hU5i+i7f3FxgEt9Qm7B6pEd7x0g@mail.gmail.com>
In-Reply-To: <alpine.DEB.2.20.1603181532040.4690@virtualbox>

On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 9 quoted lines

>
> 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