patches? -- Re: Please pull 'libertas' branch of wireless-2.6
jeff at garzik.org
Tue May 15 00:56:20 EDT 2007
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
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:
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:
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.
More information about the libertas-dev