Message-id: <alpine.LFD.1.10.0807171402110.2965@localhost.localdomain>
Date:	Thu, 17 Jul 2008 14:49:04 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org
Subject: Re: Please pull ACPI updates

Andi, Jesse, Linus,

Thanks for working through this while I'm away.

Patches with cross-tree dependencies happen,
and they continue to be a challenge to our process.
We don't really have an organized way to handle them.
It seems that every time they are a communication challenge
and I'm sorry I wasn't there to hold up my
end of the communication on this merge.

Jesse,

I use Tony Luck's topic-branch scheme, now part of the git manual:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#maintaining-topic-branches

Re: updating history in git
yes, this is an sort of an oxymoron, but it is necessary
for a "middle-man" maintainer.
On one hand, we need to test exactly what is checked in,
and on the other hand, not every test passes...
So we need to revise what we checked in before it goes upstream
and becomes permanent history.

The alternative would be to check in a lot of reverts
and incremental patches that make the final history
sent to linus really confusing.

I find that the topic branches help a lot with this.
My "test" branch is the merge of a bunch of topic branches.
If a topic branch turns out to be bad, I can re-merge my test
branch from those topics, excluding the bad one.
(or including a revised replacement).

All the branches besides the revised one maintain
their place in history.  So if they used to work,
they shoulds still work.  Of course the merge itself
can go bad...  But my topic branches are as independent
as possible, so this is rare.

Customers of my test branch know that it can be re-based.
mm and linux-next are the main customers, and since
they re-merge from scratch each time, they're immune.
Individual developers simply deal with it as a diff,
say by using the plain-patch I export, or I do something special for them.

Sometimes I re-base topic branches to make
creating a diff of them versus a well known snapshot
(eg an -rc) easy.  This is particularly useful for
topic branches that take a long time to go upstream
b/c sometimes people want to test them, but only
against a recent baseline.

Branches pulled into "release" for linus are frozen,
or course, since Linus' tree is permanent history.
So any reverts/updates after that point have to
be real revert commits and incremental patches.

cheers,
-Len

ps.

One thing I wish I had in git is a way to make this sequence easier...

Say I have a big topic branch with 30 patches in it.
The 3rd patch turns out to have a bug in it, but the
rest of the series is okay.  Today I invoke gitk on
the branch and keep that open.
Then I create a new topic branch at the broken patch.

I always consult ~/src/git/Documentation/git-reset.txt
so I can remember the following sequence...

$ git reset --soft HEAD^
$ edit
$ git commit -a -c ORIG_HEAD

Now I've got the fixed 3rd patch checked in,
but 27 patches in the original branch are hanging
off the original broken 3rd patch.
So I git-cherry-pick 27 patches
I hope I get them in the right order and don't miss any...

It would be nice if we could somehow git rebase those
27 patches in a single command, but if we do,
that pulls with it the broken 3rd patch.

come to think of it, I can probably export 4..27 as
an mbox and then import it on top of the new 3,
maybe that is what others do.


--
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/

Powered by blists - more mailing lists