Question about git branches, features, reverts, etc on subsystem maintainers tree?

Question about git branches, features, reverts, etc on subsystem maintainers tree?

[Konrad Rzeszutek Wilk]

Hey Linus,

I am hoping you can help out. I've a branch for 3.9 which has some
code that depends on the changes to the Xen hypervisor. The changes
to the Xen hypervisor are still in flux - aka they are not baked. The
code on the Linux side that uses this is marked with EXPERIMENTAL to
ward off novices.

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

 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.

 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 .

The end result for a) and b) is the same - the amount of code that
would end up in the 'git diff --stat' is the same. It is just that
there are these abhorent git reverts in case a). The pedantic part
of me screams at the uncleanliness of a) option.

The b) is a bit like git rebase in spirit, except the only "rebase"
is that I've slimmed it down and not added new patches.

The c) is .. well, ignores the part of development where we might
need to re-engineer big parts of it (thought I doubt it, but you
never know). But those redevelopment parts can be part of v3.10.

Thoughts?

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

[Linus Torvalds]

On Tue, Feb 19, 2013 at 10:42 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.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