[PATCH] less eventcause shifts

[Dan Williams]

On Tue, 2007-12-04 at 15:29 +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 10:21 -0500, John W. Linville wrote:
> > On Tue, Dec 04, 2007 at 03:07:46PM +0000, David Woodhouse wrote:
> > > On Tue, 2007-12-04 at 09:54 -0500, John W. Linville wrote:
> > > > 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.
> > > 
> > > Ah, I understand your confusion. It reflects akpm's confusion when he
> > > first started trying to use git-bisect.
> > > 
> > > This thing is, there is no actual need for a 'set of patches'. Git isn't
> > > about patches. It's about commits and pulls. It doesn't _matter_ if you
> > > had to fix up something when you merged from Linus, because when Linus
> > > pulls from your tree, he pulls your manual merge effort too.
> > 
> > Well I'm a bit hemmed-in -- Linus pull's from Dave and Jeff, they
> > pull from me.  Both of them are a bit prone to rebasing as well.
> > Even if I just "let it ride" (i.e. didn't rebase), I would still be
> > prone to some of the merge difficulties I described when I pulled
> > duplicate patches back in from Linus later.
> > 
> > FWIW, I've seen Linus complain about dirty git history on several
> > occassions.  So even if he were pulling directly from me I imagine
> > that there would still be a need for some of this quilt-like use of
> > git to clean-up things from time to time.
> 
> Very occasionally. Never, in my experience, when I'm careful about when
> I actually merge. As I said, daily merges are probably a bad idea. :)
> 
> > Still, it is true that I might be able to maintain a more consistent
> > 'everything' branch if I weren't "serving two masters"...alas.
> 
> Yeah, I don't really mean to tell you how to handle it -- I'm just
> trying to find a way to work that actually allows me to use git
> properly, rather than forcing me in to the old method of stacks of
> patches.
> 
> Basically, trees which get rebased aren't suitable for git users to base
> their work on. It just doesn't work.
> 
> > > > [1] If your work does _not_ rely on patches already merged in my tree
> > > > then by all means just use Linus' tree.
> > > 
> > > That was my intention, right up to the point at which a bunch of
> > > libertas patches appeared in your tree :)
> > 
> > It was my understanding that you were working on top of these patches
> > anyway (i.e. not rewriting or replacing them).  Anyway they are all
> > destined for 2.6.25 so your "Linus + libertas patches" just still be
> > just as valid...?
> 
> The important question is: is the commit sha1sum the same?
> 
> And the answer is no -- the commit corresponding to a given patch may
> have a different sha1sum from day to day, in your tree, and when it
> finally gets to Linus. That's fair enough -- you deal with patches, not
> git. But it sucks for anyone who wants to use git and to base their work
> on stuff you have in those patches.
> 
> Which is why I thought we'd agreed that I'll commit libertas-related
> stuff to libertas-2.6.git for now, where Holger and I can play to our
> hearts' content, then ask you to pull when we're done.

However it works out, as long as the work in libertas-2.6 doesn't drag
out too long.  Slow and steady does not win the race here :)  Not sure
what's involved if Jeff has already pulled from John; but if not, John
could drop the current libertas set and you (david) can _ensure_ that
they get into libertas-2.6 so nothing gets dropped on the floor.

Dan