patches? -- Re: Please pull 'libertas' branch of wireless-2.6

[Jeff Garzik]

Dan Williams wrote:
> On Thu, 2007-05-10 at 17:32 -0400, Jeff Garzik wrote:
>> Dan Williams wrote:
>>> Most of them are cherry-picked or backported to wireless-2.6 from
>>> libertas-2.6, the sparse fixes and the 64-bit fixes will be re-done for
>>> libertas-2.6, and then we'll merge wireless-2.6 into libertas-2.6 and
>>> send linville a pull request to pull libertas-2.6 into wireless-dev for
>>> 2.6.23 or whatever.
>>
>> Maybe you already know this, and if so, I apologize in advance, but it 
>> feels like there is a bit of a disconnect with regards to merging across 
>> all these repositories.
>>
>> Unless you are using git-rebase, going from wireless-2.6 -> libertas-2.6 
>> -> wireless-2.6 -> netdev-2.6 -> linux-2.6 will drag along quite a bit 
>> of unnecessary history.  For upstream, we'll want a clean history.
>>
>> As is normal when a driver first goes upstream, there is a bit of pain 
>> involved in switching development processes from "in my tree" to 
>> "upstream ASAP" mode.  You will likely need to just cherrypick the 
>> remaining not-yet-upstream work, into a fresh and clean repository, 
>> based off of current linux-2.6.git.
> 
> That's going to be, um, fun...  There's been a lot of libertas work
> (including a sane split of the driver so it works with CF and SDIO
> variants) since the patch marcelo posted a month or two ago; but I guess
> we can give it a shot.  Any tips on how to cherry-pick stuff more
> easily, given that the patches I'll be posting are spread out over the
> past two months, rather than in-sequence with libertas-2.6?
> 
> Otherwise we'll just brute force the cherry-picking and fix up the
> conflicts as we go, I guess.

I hope it's OK to expand this to the libertas list?  If not, I apologize 
in advance.

I always develop code in git on a branch, because that allows easy 
merging with upstream.  The vanilla, unmodified Linus tree is always 
branch 'master', and my changes are on another branch, branched from the 
current 'master' commit.

In this way, when a new release appears, I can easily merge it:

	cd /spare/repo/netdev-2.6
	git checkout master
	git pull ../linux-2.6	# my copy of vanilla repo
	git checkout upstream	# my changes are here
	git pull . master	# merge latest upstream into my stuff

At that point, you can easily see what changes are not yet upstream:

	git log master..upstream

or get a diff against upstream:

	git diff master..upstream

For libertas-2.6, that's just half the story, because unneeded history 
is still present.  That requires a rebase.  Using the same example 
branches as above, this illustrates importing updates from upstream:

	cd /spare/repo/netdev-2.6
	git checkout master
	git pull ../linux-2.6
	git checkout upstream
	git rebase master

What's the difference?  Rebase creates a new branch starting at the 
commit referenced in 'master', and applies all your changes on top of 
that commit.  Creates a clean history.

The downside is that merges are sometimes more difficult with rebase 
than the more straightforward "git pull . master" merge.

A hybrid approach is sometimes the path of least pain:

* update 'master' to 2.6.22-rc1 commit (/not/ the tag)
* do a simple merge, via 'git pull . master'
* update 'master' to the post-rc1 commits
* do a rebase

But in the end, it's a pain in the ass no matter how you look at it :/

Luckily it's a one-time pain.  Once over the "hump," merges with 
upstream will be much easier.

	Jeff