Re: [GIT pull] x86 fixes for 2.6.26
From: Jesper Juhl
Date: Sat May 17 2008 - 18:45:48 EST
2008/5/17 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>:
> 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.
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
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
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
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
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@xxxxxxxxx>
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/