Messages in this thread | | | Date | Sun, 18 May 2008 00:45:24 +0200 | From | "Jesper Juhl" <> | Subject | Re: [GIT pull] x86 fixes for 2.6.26 |
| |
2008/5/17 Linus Torvalds <torvalds@linux-foundation.org>: > > > On Fri, 16 May 2008, Theodore Tso wrote: >> >> Why do you consider rebasing topic branches a bad thing? > > Rebasing branches is absolutely not a bad thing for individual developers. > > But it *is* a bad thing for a subsystem maintainer. > <snip very nice description of when to use rebase> > > BUT if you're a subsystem maintainer, and other people are supposed to be > able to pull from you, and you're supposed to merge other peoples work, > then rebasing is a *horrible* workflow. > <snip stuff on fetch + merge> > In other words, I very heavily would suggest that subsystem maintainers - > at least of the bigger subsystems, really see themselves as being in the > same situation I am: rather than doing the work, trying to make it easy > for *others* to do the work, and then just pulling the result. >
Linus,
Thank you for some very good descriptions on proper git workflow. That was very informative.
As new Trivial tree maintainer I'm trying to figure out how I should manage that tree, and based on your description on git use I have a few questions.
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.
This is what I think I should be doing going forward. I'd appreciate it if you could comment on whether or not it's the right way to do things.
Start off with a clone of your tree (master branch).
Pull your tree into 'master' daily (or at least often).
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.
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.
As for linux-next, I'd create a 'linux-next' branch that I would update whenever I change one of the 'for-linux-2.6.xx' branches, by doing a fetch from the branch into 'linux-next' and then a merge.
Does that sound sane or is there a better way?
-- 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
| |