[lkml]   [2008]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT pull] x86 fixes for 2.6.26
2008/5/17 Linus Torvalds <>:
> 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
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

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
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 <>
Don't top-post
Plain text mails only, please

 \ /
  Last update: 2008-05-18 00:47    [W:0.123 / U:1.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site