[PATCH] less eventcause shifts

[John W. Linville]

On Mon, Dec 03, 2007 at 08:48:59PM +0000, David Woodhouse wrote:
> 
> On Mon, 2007-12-03 at 12:58 -0500, Dan Williams wrote:
> > I'm sort of sitting on these patches until you and Woodhouse start using
> > the same git tree until he's done with the command rework...  It's going
> > to be near impossible to handle both of your patches with any certainty.
> > Any progress on whether you've both been able to work in the same repo?
> 
> http://git.infradead.org/?p=libertas-2.6.git
> 
> It's based on Linus' tree -- we've abandoned John's wireless-dev tree
> altogether. He rebases it and uses branches -- it's just an exercise in
> making git hard.

Re: branches -- I don't see why they bother you.  Mostly you can just
ignore them.

Without branches I would have to have at least two trees (one for
feeding Dave, the other for feeding Jeff) and maybe a third for
development/integration, and it would be more difficult to cherry-pick
commits between them.  How would that be any better?

Re: rebasing -- again it shouldn't matter to you when I rebase most
of the branches.  All the branches besides 'everything' are there
for my own organizational purposes.

I have been rebasing 'everything' when Linus releases an -rc.  If I
don't rebase then over time it becomes a mess.  It becomes difficult
to see what is "in" and what is "out", you get duplicate changelog
entries, you get merge conflicts where there shouldn't be any, etc.
I've been through that with the old wireless-dev tree (RIP) and I
would rather not repeat it.  That said, I _do_ try to avoid rebasing
'everything' when possible.  I don't think I've rebased within an
-rc period in quite some time.

As for "making git hard", git is what makes this easy.  If you are
doing development that relies on patches already merged [1], then
you might start development based on wireless-2.6 like this:

	git clone --reference linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
	git checkout -b work origin/everything
	git branch work-start

That way you have a record of where your patches start.  From there
you happily make you commits until you want to rebase your work on
the latest wireless-2.6 tree.  Then you start by saving a copy of
your work:

	git format-patch --stdout work-start..work > work.mbox

Then you need the updated wireless-2.6.  As you point-out, it may have
been rebased -- a straight pull won't always work.  So, just save your
tree, re-clone the current wireless-2.6, and make a new work branch:

	# rename your old tree
	mv wireless-2.6 wireless-2.6-old

	# This should look familiar!
	git clone --reference linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
	git checkout -b work origin/everything
	git branch work-start

Then replay your work on top of it:

	git-am -s ../wireless-2.6-old/work.mbox

The result is a nice, rebased set of patches on top of the current
upstream work.	If you simply did a "commit, pull, commit, pull,
etc" cycle then you would end-up with a set of patches that might
no longer apply on top of a clean upstream branch -- been there,
wireless-dev RIP.

I really think this is the best methodology for processing patches
so that they are ready for merging when posted.

Hth!

John

[1] If your work does _not_ rely on patches already merged in my tree
then by all means just use Linus' tree.
-- 
John W. Linville
linville at tuxdriver.com