linux-kernel - Re: Question about git branches, features, reverts, etc on subsystem maintainers tree?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFyJwu3RS=7UJFZ0wC4A8JBE6SQdUnYHksPHSnhQdD0Z=g@mail.gmail.com>
Date:	Tue, 19 Feb 2013 11:50:37 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Question about git branches, features, reverts, etc on subsystem
 maintainers tree?

On Tue, Feb 19, 2013 at 10:42 AM, Konrad Rzeszutek Wilk
<konrad.wilk@...cle.com> wrote:
>
> To give you a 3.9 branch I am thinking to either:
>
>  a). revert the merges I've for this new feature altogether and
>      merge it later in v3.10 time-frame. They make about 50% off the
>      code in this branch, so its big chunk of code movement.
>      For 3.10 I could do a git revert of a revert and get everything
>      in at once :-)

Never revert a merge. It just results in total mess. It's "possible"
to do as a "patch that undoes the changes that the merge brought in",
but being possible doesn't make it sensible.

Reverting every commit that the merge brought in is also usually just
a f*cking mess. Unless the merge just merged a single commit (but even
then it's just not pretty).

>  b). create a new branch for you without the new features and
>      just live with the shame of having the timestamp of patches
>      being after the merge window.

For this situation, I don't think we have much choice, so (b) it is.

In general, please don't merge unfinished stuff into your main branch
at all to begin with, so that things like this don't happen. There's a
reason git people talk about "feature branches".

>  c). Rip out the Kconfig entry so there is not even an build option
>      to build it. And then if the Xen hypervisor parts are bakend,
>      add the Kconfig entry back and only deal with bug-fixes.
>      A bit like adding #ifdef 0 .

I don't like pulling stuff during the merge that is known broken. It
also makes bisection a total pain in the ass, because the bisection
will find the commit that enables the code, not the actual problematic
code. So "hide from the build" is a real problem, and should basically
never be the answer.

                   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/