Messages in this thread |  | | | Date | Mon, 19 May 2008 00:09:49 +0200 | | From | "Jesper Juhl" <> | | Subject | Re: [GIT pull] x86 fixes for 2.6.26 |
| |
2008/5/18 Linus Torvalds <torvalds@linux-foundation.org>: >
Hi Linus,
Thank you for responding. A few more small questions below.
> > 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). > Yeah, I figured that trying to get a good git workflow up and running would probably be the best in the long run.
> 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). > Right. By definition it is just a bunch of random patches queued up in that tree so they don't get lost and so that lots of individual people don't have to keep re-sending them.
> 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. > Good.
> 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). > <snip>
Ok, so let's say I start off my upcomming trivial branch at -rc1 and start applying patches to it, then doing a merge with my master branch that tracks your tree at points like, say, -rc5, -rc9 etc would be fine, but really only needed if there are conflicts (which I can test for in a temporary experimental branch) - got it.
>> 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. >
Ok, thanks a lot. Now, I have one final question for you. In order to be able to play around with the patches, see if they apply, fix them up, test for merge conflicts etc etc, I obviously need a tree with content, not just a bare tree. But I see on master.kernel.org that all the published trees are bare trees.
So, I assume I create a tree in my homedir like so; $ git clone -l -s /pub/scm/linux/kernel/git/torvalds/linux-2.6.git /home/juhl/trivial-work-tree create all the branches and do all the work in that one,
I would have assumed that to then publish my work and create a publicly accessile version I'd do; $ git clone --bare -l -s /home/juhl/trivial-work-tree /pub/scm/linux/kernel/git/juhl/trivial.git
But that only seems to make my master branch accessible, not new branches I create in my work tree. How do I go about doing this properly?
-- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html
|  |