Linville update wireless-2.6/everything

Dan Williams dcbw at redhat.com
Tue Dec 4 12:08:12 EST 2007


On Tue, 2007-12-04 at 17:02 +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 11:44 -0500, John W. Linville wrote:
> > On Tue, Dec 04, 2007 at 04:20:55PM +0000, David Woodhouse wrote:
> > > The important difference is that a 'patch' can be committed many times
> > > in many different places in many different git trees (or branches).
> > > That's many _different_ git-commits. But only one patch.
> > 
> > This is a technical detail.  Getting the patch merged is the important
> > part, the point of the exercise.
> > 
> > > People who use git will base their work on a given commit. And if that
> > > commit suddenly disappears in a rebase or re-commit, and never makes it
> > > into Linus' tree, that's a pain.
> > 
> > Yes, pain that can be minimized downstream by following a simple git
> > procedure and following the principle of "merge early and often".
> 
> All the above basically throws away the advantages which make git so,
> well, advantageous.
> 
> You're right; there are ways of dealing with the pain, and when it comes
> down to it, it really is just about getting the patches merged.
> 
> It just sucks that we have this tool and we're not even _using_ it to
> its full effect (for network code).
> 
> > > > FWIW I haven't rebased 'everything' yet, although I do plan to rebase
> > > > on -rc4 soon.
> > > 
> > > Right. Which is why I chose _not_ to base my git tree on yours, but on
> > > Linus' tree.
> > 
> > ...where a number of libertas patches are not currently available
> > (which was already true before last night's merging)...
> 
> That's where we came in. Can we commit libertas patches _only_ to the
> libertas tree now, and not send them through the other convoluted
> non-git process please?

Yes, but understand that in the end the result has to get pulled by
Linville.  So you'll have to do a rebase to wireless-2.6/everything
anyway or at least figure out some other way to ensure there aren't any
merge conflicts before sending John the pull request.  But I'm sure you
know that.

dan

> I thought we'd agreed to that on IRC a few days ago; I must have
> misunderstood. 
> 
> Let's draw a line under the _commits_ (not patches) you've already sent
> upstream, and I'll base my tree on those. Where are they?
> 
> > > > I don't really see the conflict.  It just seems to me that the pain
> > > > is all mine -- when you are done I pull your tree, figure-out which
> > > > commits are new, and reapply them on top of whatever is current.
> > > > What is the big deal?
> > > 
> > > That's true to a certain extent, but I was trying to _avoid_ causing
> > > that pain. If you weren't keeping libertas patches in your patch-stack,
> > > then there would be no pain. You'd just have a clean tree to pull from.
> > 
> > The big "rename everthing libertas_ to lbs_" patch was already sent
> > toward 2.6.25.  Doesn't that render the whole "clean tree" theory moot?
> 
> Yes, it does. That's why I wanted to have it _just_ in the libertas
> tree, and not have it recommitted elsewhere as a completely different
> commit. But now you've sent it upstream, I'll throw away my tree and
> base on your commits instead.
> 
> > I'm sorry, I just don't have the luxury of only sending pristine
> > commits to Linus.  I have to coordinate with jgarzik and davem, and
> > they usually rebase their trees before pushing to Linus in the merge
> > window anyway.  So I push them commits representing patches that
> > apply at the top of the stack.  That way your patches get merged,
> > even though your commits are lost.  It is the best I can do.
> 
> I understand. If I were you, I'd avoid using their trees as much as
> possible -- I'd work directly on Linus' tree, and also push directly to
> Linus. How often do you _actually_ depend on patches which are in
> davem's or jgarzik's trees anyway? Or more to the point, how often
> _would_ you depend on such patches, if you were trying to avoid it? 
> 
> But I don't really mean to tell you how to do the job. I was just saying
> that _I_ would like to use git (as git), which I don't think is a
> particularly unreasonable desire, and that I would therefore prefer to
> have a separate libertas tree based directly on Linus tree. And thus,
> please can we try to make sure that libertas patches from now on go that
> way rather than through the mangler?
> 
> Yes, of course I'll try to make sure that stuff is fed upstream early
> and often. That makes sense -- and the failure to do that, along with
> merging of OLPC-specific hacks which should never have seen the light of
> day, is what led to the original mess with the libertas tree. Don't be
> put off by that.
> 




More information about the libertas-dev mailing list