Message-ID: <alpine.LFD.1.10.0805171715540.3020@woody.linux-foundation.org>
Date:	Sat, 17 May 2008 17:35:44 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesper Juhl <jesper.juhl@...il.com>
cc:	Theodore Tso <tytso@....edu>, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] x86 fixes for 2.6.26



On Sun, 18 May 2008, Jesper Juhl wrote:
> 
> What I did for my first merge-window was simply clone your tree,
> create a for-linus branch, add all the patches to that branch and ask
> you to pull. That worked nicely that once, but I guess that wiping the
> tree and starting from a fresh clone every merge window wouldn't be a
> good idea - especially since I'd like Trivial to also get pulled into
> linux-next.

Well, I actually suspect that especially for the trivial tree, that may 
not actually be a horribly bad workflow. 

The whole "fresh clone + a bunch of patches" is yet another different way 
of using git, but it's a totally valid one: it uses git as just another 
way to send a patch-series, with the added advantage that the base of that 
patch-series is explicit in the result.

(You can do that with quilt too, I think. Or at least with the scripts 
Andrew does - I think you can tell him what the base point for a series 
is. But when merging to me, git is obviously the way to go).

So for something that pretty fundamentally is literally just a series of 
random patches, I don't think the workflow of just staging them as a 
series on top of some known-good git tree is the wrong one. It's not like 
the Trivial tree is likely to be something that would have much use of git 
as a distributed model (iow - I think the trivial patches are actually 
better off seen as a patch-queue than having merges and other things in 
it).

That said, re-cloning every time is obviously pretty wasteful. There are 
better ways to track a git tree, notably it's likely best to just clone 
once and then just keep that one up-to-date. But the difference between 
that and just re-cloning is really not that huge - technically you'd end 
up doing the exact same thing and have the exact same tree, just two 
different ways to do it.

So your alternate approach:

> Start off with a clone of your tree (master branch).
> 
> Pull your tree into 'master' daily (or at least often).

So doing daily pull's is what I generally do *not* want people to do, but 
if you have a pristine tree and haven't done any development of your own, 
then the "pull" is obviously not going to do anything but keep the tree 
fresh, so in this special case it's fine.

So you'd not be merging, you'd be just refreshing your clone - and in that 
sense this is 100% equivalent to just re-cloning all the time.

> Create a for-linux-2.6.27 branch or the upcomming 2.6.27 merge window
> and apply all the patches I currently have pendng in a mailbox to that
> branch. Keep the branch reasonably up-to-date by doing a weekly git
> fetch + merge from my 'master' branch that tracks your tree.

So generally, I'd suggest against this "keep it fresh". In many ways it 
just makes things harder (if only because bisection of your series will no 
longer be a nice linear run, but also because the history will actually be 
harder to read), and if the merges are just weekly regular merges, then 
the purpose of them isn't even very clear.

So I'd literally suggest doing merges primarily only

 - at release points (now the purpose is clear; you're merging a very 
   specific state, not just some random point).

   But even this one should generally be done only if there is some real 
   reason for it (ie you're really quite far behind), and 

 - or if you actually see a merge conflict, and you want to handle the 
   conflict so that I won't have to.

   But I'll actually happily handle trivial merges too, so this is by no 
   means even a requirement - if the merge ends up being non-trivial, I'll 
   let people know anyway and either say "ok, that's so complicated, and I 
   don't know the area well enough, so can you please do it for me", or 
   say "ok, I merged it, but can you please double-check the result".

Quite frankly, if you actually do your patch-series pretty late in the -rc 
series (say, you decide to apply things at -rc6 or so), I suspect you'll 
never have any real reason to do a "git pull" at all, although it's also 
certainly not wrong to do test branches to check that everything is ok, 
for example.

> Once the 2.6.27 merge window opens, ask you to pull the
> 'for-linux-2.6.27' branch and once you have done so, leave that branch
> alone forever.
>
> Branch off a new 'for-linux-2.6.28' branch and repeat.

Yes. That's a good model.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists