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:
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.
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.
Yes. That's a good model.
Linus
--
