From: Theodore Tso <tytso@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 16, 9:57 pm 2008

On Fri, May 16, 2008 at 03:47:53PM -0700, Linus Torvalds wrote:

> Do nice topic branches, where each branch has a reason for existing. The

> "x86-fixes-for-linus" branch has x86 fixes.

>

> This happens almost every time somebody starts using git properly: at that

> point the rebasing no longer hides bad habits.
Why do you consider rebasing topic branches a bad thing?  It does help

keep the history much cleaner, and it means that I can test to make

sure the topic branch works well with the latest head of the

development branch.
Is there a write up of what you consider the "proper" git workflow?
   	   	       	    		     	      - Ted

--



From: Linus Torvalds <torvalds@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 16, 11:19 pm 2008

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.
So I would heartily recommend that if you're a "random developer" and

you're never going to have anybody really pull from you and you

*definitely* don't want to pull from other peoples (except the ones that

you consider to be "strictly upstream" from you!), then you should often

plan on keeping your own set of patches as a nice linear regression.
And the best way to do that is very much by rebasing them.
That is, for example, what I do myself with all my git patches, since in

git I'm not the maintainer, but instead send out my changes as emails to

the git mailing list and to Junio.
So for that end-point-developer situation "git rebase" is absolutely the

right thing to do. You can keep your patches nicely up-to-date and always

at the top of your history, and basically use git as an efficient

patch-queue manager that remembers *your* patches, while at the same time

making it possible to efficiently synchronize with a distributed up-stream

maintainer.
So doing "git fetch + git rebase" is *wonderful* if all you keep track of

is your own patches, and nobody else ever cares until they get merged into

somebody elses tree (and quite often, sending the patches by email is a

common situation for this kind of workflow, rather than actually doing git

merges at all!)
So I think 'git rebase' has been a great tool, and is absolutely worth

knowing and using.
*BUT*. And this is a pretty big 'but'.
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.
Why?
It's horrible for multiple reasons. The primary one being because nobody

else can depend on your work any more. It can change at any point in time,

so nobody but a temporary tree (like your "linux-next release of the day"

or "-mm of the week" thing) can really pull from you sanely. Because each

time you do a rebase, you'll pull the rug from under them, and they have

to re-do everything they did last time they tried to track your work.
But there's a secondary reason, which is more indirect, but despite that

perhaps even more important, at least in the long run. 
If you are a top-level maintainer or an active subsystem, like Ingo or

Thomas are, you are a pretty central person. That means that you'd better

be working on the *assumption* that you personally aren't actually going

to do most of the actual coding (at least not in the long run), but that

your work is to try to vet and merge other peoples patches rather than

primarily to write them yourself.
And that in turn means that you're basically where I am, and where I was

before BK, and that should tell you something. I think a lot of people

are a lot happier with how I can take their work these days than they

were six+ years ago.
So you can either try to drink from the firehose and inevitably be bitched

about because you're holding something up or not giving something the

attention it deserves, or you can try to make sure that you can let others

help you. And you'd better select the "let other people help you", because

otherwise you _will_ burn out. It's not a matter of "if", but of "when".
Now, this isn't a big issue for some subsystems. If you're working in a

pretty isolated area, and you get perhaps one or two patches on average

per day, you can happily basically work like a patch-queue, and then other

peoples patches aren't actually all that different from your own patches,

and you can basically just rebase and work everything by emailing patches

around. Big deal.
But for something like the whole x86 architecture, that's not what te

situation is. The x86 merge isn't "one or two patches per day". It easily

gets a thousand commits or more per release. That's a LOT. It's not quite

as much as the networking layer (counting drivers and general networking

combined), but it's in that kind of ballpark.
And when you're in that kind of ballpark, you should at least think of

yourself as being where I was six+ years ago before BK. You should really

seriously try to make sure that you are *not* the single point of failure,

and you should plan on doing git merges.
And that absolutely *requires* that you not rebase. If you rebase, the

people down-stream from you cannot effectively work with your git tree

directly, and you cannot merge their work and then rebase without SCREWING

UP their work.
And I realize that the x86 tree doesn't do git merges from other

sub-maintaines of x86 stuff, and I think that's a problem waiting to

happen. It's not a problem as long as Ingo and Thomas are on the net every

single day, 12 hours a day, and respond to everything. But speaking from

experience, you can try to do that for a decade, but it won't really work.
I've talked to Ingo about this a bit, and I'm personally fairly convinced

that part of the friction with Ingo has been that micro-management on a

per-patch level. I should know. I used to do it myself. And I still do it,

but now I do it only for really "core" stuff. So now I get involved in

stuff like really core VM locking, or the whole BKL thing, but on the

whole I try to be the anti-thesis of a micro-manager, and just pull from

the submaintainers.
It's easier for me, but more importantly, it's actually easier for

everybody *else*, as long as we can get the right flow working.
Which is why I still spend time on git, but even more so, why I also try

to spend a fair amount of time on explaining flow issues like this.

Because I want to try to get people on the same page when it comes to how

patches flow - because that makes it easier for *everybody* in the end.
[ IOW, from my personal perspective, in the short run the easiest thing to

  do is always "just pull".
  But in the long run, I want to know I can pull in the future too, and

  part of that means that I try to explain what I expect from downstream,

  but part of that also means that I try to push down-stream developers

  into directions where I think they'll be more productive and less

  stressed out so that they'll hopefully *be* there in the long run.
  And I think both Ingo and Thomas would be more produtive and less

  stressed out if they could actually pull from some submaintainers of

  their own, and try to "spread the load" a bit. It involves them finding

  the right people they can trust, but it also involves them having a

  workflow in place that _allows_ those kinds of people to then work with

  them! ]
> Is there a write up of what you consider the "proper" git workflow?
See above. It really depends on where in the work-flow you are.
And it very much does depend on just how big the flow of patches is. For

example, during 2.6.24..26, net/ and drivers/net had ~2500 commits.

arch/x86 and include/asm-x86 had ~1300 commits. Those are both big

numbers. We're talking a constant stream of work.
But Ted, when you look at fs/ext4, you had what, 67 commits in the

2.6.24..25 window? That's a whole different ballgame. If you have 67

commits in a release window of two months, we're talking roughly one a

day, and you probably didn't have a single real conflict with anybody else

during that whole release window, did you?
In *that* situation, you don't need to try to stream-line the merging. You

are better off thinking of them as individual patches, and passing them

around as emails on the ext4 mailing lists. People won't burn out from

handling an average of one patch a day, even for long long times. Agreed?
Realistically, not many subsystems really need to try to find

sub-sub-maintainers. Of the architectures, x86 is the most active one

*by*far*. That said, I think PowerPC actually has a chain of maintenance

that is better structured, in that there is more of a network of people

who have their own areas and they pull from each other. And POWERPC only

has about half the number commits that x86 has. I bet that lower number of

commits, coupled with the more spread out maintenance situation makes it

*much* more relaxed for everybody.
Networking, as mentioned, is about twice the number of patches (in

aggregate) from x86, but the network layer too has a multi-layer

maintenance setup, so I suspect that it's actually more relaxed about that

*bigger* flow of commits than arch/x86 is. Of course, that's fairly

recent: David had to change how he works, exactly so that the people who

work with him don't have to jump through hoops in order to synchronize

with his tree.
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

--



From: Theodore Tso <tytso@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 17, 10:58 am 2008

On Fri, May 16, 2008 at 08:19:04PM -0700, Linus Torvalds 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.
Right, but so long as a subsystem maintainer doesn't publish his/her

topic branches, and only sends out patches on their topic branches for

discussion via e-mail, they're fine, right?  They can just rebase up

until the point where the patch goes on a non-'pu' or non-'linux-next'

branch.
Basically, this would be the subsystem maintainer sometimes wearing an

"end-point-developer" hat, and sometimes wearing a "subsystem

maintainer" hat.  So rebasing is fine as long as it's clear that it's

happening on branches which are not meant as a base for

submaintainers.  
I believe Junio does this himself for his own topic branches while

developing git, yes?  And that's probably a good reason for him not

actually *publishing* any of his topic branches, and only the 'pu'

branch, which is well known to be a bad idea for folks to use as a

branch point, since it is constantly getting rebased.
> And I realize that the x86 tree doesn't do git merges from other

> sub-maintaines of x86 stuff, and I think that's a problem waiting to

> happen. It's not a problem as long as Ingo and Thomas are on the net every

> single day, 12 hours a day, and respond to everything. But speaking from

> experience, you can try to do that for a decade, but it won't really work.

>

> I've talked to Ingo about this a bit, and I'm personally fairly convinced

> that part of the friction with Ingo has been that micro-management on a

> per-patch level. I should know. I used to do it myself. And I still do it,

> but now I do it only for really "core" stuff. So now I get involved in

> stuff like really core VM locking, or the whole BKL thing, but on the

> whole I try to be the anti-thesis of a micro-manager, and just pull from

> the submaintainers.
Heh, can't really argue with your point here.
							- Ted

--



From: Linus Torvalds <torvalds@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 17, 1:05 pm 2008

On Sat, 17 May 2008, Theodore Tso wrote:

>

> Right, but so long as a subsystem maintainer doesn't publish his/her

> topic branches, and only sends out patches on their topic branches for

> discussion via e-mail, they're fine, right?
Yes. But then you really cannot work with other people with git.
That's what i was saying - you can use "git rebase" as long as you're a

"leaf developer" from a git standpoint, and everything you do is just

emailing patches around. 
And quite frankly, if the x86 maintainer is a "leaf developer", we are

going to be in trouble in the long run. Unless some other architecture

comes out an takes away all the users and developers (which obviously

isn't going to happen).
> Basically, this would be the subsystem maintainer sometimes wearing an

> "end-point-developer" hat, and sometimes wearing a "subsystem

> maintainer" hat.  So rebasing is fine as long as it's clear that it's

> happening on branches which are not meant as a base for

> submaintainers.  
It's not about "not meant as a base". It's about "cannot *possibly* be a

base". And the difference is that while *you* may not want others to base

their work off it, are you sure others agree?
And realize that while "git rebase" may be making things easier for the

person that does the rebase, what it ends up doing for *others* is to take

away options from them, and making for more work for them.
Again, if there are not enough others to matter, then you _should_ make

the workflow be around your own personal sandbox. So 'git rebase' makes

sense then.
Basically, it boils down to whether you're a technical manager or a grunt. 
A grunt should use 'git rebase' to keep his own work in line. A technical

manager, while he hopefully does some useful work on his own, should

strive to make _others_ do as much work as possible, and then 'git rebase'

is the wrong thing, because it will always make it harder for the people

around you to track your tree and to help you update your tree.
And it's absolutely true that Ingo has been a 'grunt' in many ways. Not

only does everybody start out that way, but if you ask the question "who

does the actual work" (as a way to find out who is not a manager, because

managers by definition are useless bloodsucking parasites), then Ingo

clearly doesn't look very managerial.
But I definitely think we want Ingo and Thomas to be managers, not grunts. 
Yes, both Ingo and Thomas are the top committers when looked at

individually. Here's the top five committers since 2.6.24 in arch/x86:
	Ingo Molnar (194):

	Thomas Gleixner (125):

	Glauber de Oliveira Costa (117):

	Roland McGrath (103):

	Glauber Costa (92):

	...
and in that sense they look very much non-managerial. But those ~200

commits are still just two hundred out of 1900 commits total! We *need*

managers, not just grunts. And I can well imagine how stressful it is to

not just do the two hundred commits, but also try to orchestrate the other

~1700 ones.
			Linus

--



From: Junio C Hamano <gitster@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 17, 4:26 pm 2008

Theodore Tso  writes:
> Basically, this would be the subsystem maintainer sometimes wearing an

> "end-point-developer" hat, and sometimes wearing a "subsystem

> maintainer" hat.  So rebasing is fine as long as it's clear that it's

> happening on branches which are not meant as a base for

> submaintainers.

>

> I believe Junio does this himself for his own topic branches while

> developing git, yes?
Yes, I used to and I still do sometimes.  Anything not merged to 'next'

yet is a fair game for rebasing.  'pu' is strictly a patch queue in that

sense.
When I am shuffling the topics that are not merged to 'next', I am not

just wearing an end-point-developer hat, but pretending to be the original

contributor (iow "how the patch could have been done better than the one

that I received via e-mail") more often than not these days; I am writing

less and less new code myself.
I used to religiously rebase topics that were not in 'next' on top of

updated 'master' before I rebuilt 'pu' [*1*].  This was partly because

when the topic eventually becomes 'next' worthy, the commit on 'next' to

merge the topic will not have a parent that is too stale (and graphically

the end result would look easier to view that way) if I did so, and partly

because rebasing is one cheap way to detect and resolve conflicts with

'master' much earlier before the topic becomes ready to be merged to

'next'.
I do not however do that so often anymore.
Whenever I rebuild 'pu' starting from the tip of 'next', merging these

uncooked topics, if they have conflicts with 'master' or 'next', I'd

resolve them right there.  Next day, when I rebuild 'pu' again from

updated 'next', it is very likely that I have to resolve the _same_

conflicts again, but that process is largely automated because git

remembers the conflict resolution I did when I merged that topic to 'pu'

the previous day.  After the topics are polished further and when they are

ready to be merged to 'next', the story is the same.  The same conflicts

need to be resolved but that is largely automated.  That is one of the

reasons I do not rebase topics as often as I used to these days.  IOW, I

rely on and trust "rerere" magic a bit more than I used to.
[Footnote]
*1* My "git day" goes like:
 - advance 'maint' with obviously good patches, merges from completed

   'maintenance' topics, and merges from subsystem trees;
 - merge updated 'maint' to 'master';
 - advance 'master' with obviously good patches, merges from completed

   topics, and merges from subsystem trees;
 - merge updated 'master' to 'next';
 - apply new patches into new topics forked from either 'maint' (if it

   should eventually fix breakage in the maintenance track), 'master', or

   some existing topic (if it has functional dependencies on it);
 - apply update patches to existing topics;
 - possibly rebase topics that have not been in 'next' but are now ready

   for 'next';
 - merge topics that are 'next' worthy to 'next';
 - reset 'pu' to 'next';
 - merge remaining topics to 'pu';

--

From: Jesper Juhl <jesper.juhl@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 17, 6:45 pm 2008

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.

>
>

> 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.

>
> 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

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

--



From: Linus Torvalds <torvalds@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 17, 8:35 pm 2008

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).
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:
> 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.
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).
   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.
> 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.
			Linus

--



From: Jesper Juhl <jesper.juhl@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 18, 6:09 pm 2008

2008/5/18 Linus Torvalds :

>
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).

>
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

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

--



From: Linus Torvalds <torvalds@...>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: May 18, 6:26 pm 2008

On Mon, 19 May 2008, Jesper Juhl wrote:

>

> 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.
I think just about *everybody* does their own development on their own

machine. I know I do, and I'm pretty certain that everybody else does too.

Then we just upload the end result to master.kernel.org into a bare

repository that is only used for exporting to others, never for anything

else.
> 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,
You can do that, and actually work on master.kernel.org, but do you really

want to?
It's much easier to work at home (or office, whatever - on your own

workstation), unless you have some really weak computer.
Then, the easiest way to publish the result is to just create a bare

repository on master.kernel.org, and push to it. And just make sure that

you pre-populate that bare repo with my tree, so that when you push from

your home machine, it only pushes the (smallish) actual changes!
So the workflow I'd suggest is:
 - do all the work on your own hardware
 - create the initial (bare) kernel.org tree with
	cd /pub/scm/linux/kernel/git/juhl

	git clone --bare -l -s ../torvalds/linux-2.6 trivial-2.6
 - then just push to that tree from your own machine
and voila, you're all done.
> 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?
If you do the "clone locally, then push from the remote", the "push" stage

is when you decide which branches you'll want to push.
The easiest thing to do is to just use "--all", which will push all the

branches to the remote (you may want to use "--force" if this ends up

being a non-fast-forward, which can happen - for example - just because

your "clone" might have cloned a later version of my tree than the one you

based your own 'master' branch off).
But you can push individual branches too, see 'man git-push'.
If you really *want* to work on master.kernel.org, you can do so, and you

can do the final clone with "git clone --mirror --bare" and use that as a

way to clone all branches as a mirror of your work-tree, but it really is

a fairly unusual way to work.
		Linus

--