linux-kernel - Re: git process question

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] [day] [month] [year] [list]

Message-ID: <CA+55aFzXtuP2G+Zxwhp86_KPZw0aUQzQdRMz_irwWPRChBMZKg@mail.gmail.com>
Date:   Wed, 19 Apr 2017 16:03:45 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: git process question

On Wed, Apr 19, 2017 at 3:39 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
> Steven Rostedt <rostedt@...dmis.org> writes:
>>
>> Would it be OK to cherry pick this change that I send to you, which
>> will be based on a commit in your tree, into my development branch
>> where I can continue the work on top of the previous development that's
>> in linux-next and the fix?
> ...
>> The alternatives are,
> ...
>>  2) Merge the development and urgent branches and continue working on
>>     that. But I understand that you really don't like it when people do that.
>                                       ^^^^^^^^^^^^^^^^^^^^
>                                       Is this part actually true?
>
> I ask because I have done it a few times and thought it was OK in
> general if there's a good reason for it.

So I have seen *so* many bad merges from submaintainers that I do
discourage them, simply because I see a lot of merges without proper
explanations for why the merge happened or what is going on.

It's not that merges like that are necessarily wrong, and they clearly
exist, but cherry-picking can actually be the better solution.

If you do merge, make sure to explain why you merge. And you should
strive to never do a back-merge of other peoples code, so the "merge
into my own development tree" is mainly a good option if the stable
branch you are merging only contains your own stuff.

Which it almost never does. People will have started their branches at
different points, and the merge suddenly changes a lot of other things
than just bringing in a fix. So a small cherry-pick can be the much
simpler solution to bring in a fix without bringing in other random
stuff.

But things are never entirely black-and-white,. so there's no single
"one correct way".

                Linus