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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Mar 2016 08:43:30 -0700
From:	Junio C Hamano <gitster@...ox.com>
To:	Johannes Schindelin <Johannes.Schindelin@....de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Laxman Dewangan <ldewangan@...dia.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio\@vger.kernel.org" <linux-gpio@...r.kernel.org>,
	Git Mailing List <git@...r.kernel.org>
Subject: Re: [GIT PULL] GPIO bulk changes for kernel v4.6

Johannes Schindelin <Johannes.Schindelin@....de> 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).