Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757526AbcCRPng (ORCPT ); Fri, 18 Mar 2016 11:43:36 -0400 Received: from pb-smtp0.pobox.com ([208.72.237.35]:54221 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752558AbcCRPne (ORCPT ); Fri, 18 Mar 2016 11:43:34 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=mau8PgTKUzapVBAecMK9/VXiM/Q/G/1x CLpSC1YZ6HfBpMyX5y/ltWwszB6GmJhx1GNLvoiHOaHxwb83DUG25rHvvBwMzBxe Ap3R7tt8tPh6txFSjG0c9egU2GSRa7iyONma+el6WzHOSfwvghvznjOr0hRe5OZV WGTQ61ExrPc= From: Junio C Hamano To: Johannes Schindelin Cc: Linus Torvalds , Laxman Dewangan , Linus Walleij , "linux-kernel\@vger.kernel.org" , "linux-gpio\@vger.kernel.org" , Git Mailing List Subject: Re: [GIT PULL] GPIO bulk changes for kernel v4.6 References: <56EB9B0C.4050507@nvidia.com> Date: Fri, 18 Mar 2016 08:43:30 -0700 In-Reply-To: (Johannes Schindelin's message of "Fri, 18 Mar 2016 15:32:54 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 2AFE1EB4-ED20-11E5-981F-79226BB36C07-77302942!pb-smtp0.pobox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1809 Lines: 43 Johannes Schindelin writes: > Hi Linus, > > 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/ > > Ciao, > Dscho An obvious response to the above, "What about it?", is something you would have already anticipated when you wrote the above, and I wish I saw that in the message I am responding to, but I didn't, so here is my attempt ;-) The old article shows two interesting things. One is that there are cases where it makes perfect sense to bind two unrelated histories when the two roots are totally unrelated. I am not Linus, but I think the proposal is to make it harder to do this unusual merge by mistake, while keeping it possible to do so when the user really wants to. And the "deliberately whitespace damaged patch" in the message you are responding to was primarily to point out where the "making it harder" logic should go by showing how to make it impossible, leaving it to readers to adjust it to "harder but still possible". Now, the second thing that the old article you pointed shows is that it is possible to create such a merge without using "git merge" even though it is more involved and takes conscious effort by the user. In that sense, you could argue that, with the "make it impossible" change in Linus's message to "git merge", there is no more change needed (I do not know if that is what you meant to imply, though). I think it makes sense to teach "git merge" to error out like Linus did unless the user explicitly says "I know what I am doing" with an explicit option (e.g. --force or --merge-unrelated-histories).