[pnfs] A git-tree with my last 19 linux-pnfs-2.6-latest READI/O patches

[Boaz Harrosh]

On Tue, Dec 04 2007 at 7:54 +0200, Benny Halevy <bhalevy at panasas.com> wrote:
> Labiaga, Ricardo wrote:
>>> Well, it's a tradeoff.  You're essentially restarting the history from
>>> scratch each time.  That means for example if someone else is building
>>> work on top of your work, then they have to manually figure out where
>>> their series ended and your patches began in order to port 
>>> them forward
>>> to a new version of your branch.
>>>     
>> What I'm hearing from Benny leads me to think that every patch gets
>> rebased multiple times until we're ready to push upstream.  So basically
>> any new work needs to be manually figured out from now till we push it?
>> That would be months of manual work by all of us over and over.  I'm
>> probably missing something.
>>   
> That's right but:
> a. the porting work is done in any case. it just finds its way to the 
> merge commits rather than the patches.
> b. doing that in small increments shouldn't take a lot of effort and it 
> really helps you with understanding
> what's coming up the stream and your dependencies on it.
>> I suspect an example would clear this up...  
>>   
Bruce I will need your help here
Let me have a shot at it, have a sit it's long:

If you want to avoid trouble with cloned trees and pulls (merges)
Than all you need to do is keep master as a "from Linus" without any
NFS/pNFS work at all. 

(All the trouble with master is that it is a local branch that tries to 
stick/float to the origin/master but if the origin/master was rebased 
than the local old-patches are not removed before an attempt to merge 
with the new-but-same patches of origin/master and they conflict.
What you do in this case is on the local master do a git-reset --hard to
any common ancestor of master with origin/master and do git-pull,
now it will succeed)

So we agree for pnfs.git/master to be a clone of Linus tree at any given
time.

2. Than have, lets say sessions branch by:
# git-checkout -b sessions master
commit all patches belong to sessions
# git-checkout -b pnfs sessions
commit all pnfs patches.

now we have a git-format-patch able tree with two distinct
patchsets ready to be sent upstream at any time. But how do we
proceed?

Lets say I'm Benny and I do some new development on pnfs
# git-clone git://....../pnfs.git
# git-checkout -b mypnfs-todo-draftXX origin/pnfs
patch patch edit patch commits ...
Send new patch(s) upstream these are applied cleanly on top
of pnfs branch. Now Benny wants to update with other people
patches

[A]
# git-checkout master
# git-pull

if all of his mypnfs-todo-draftXX are in upstream than the branch
is just abandoned and is left for nostalgia. If not what he does is
[B]
# git-checkout mypnfs-todo-draftXX
# git-rebase(--interactive) origin/pnfs

He will note that his "accepted" patches are no longer in the rebase
list as git identified returned (exactly the same) patches and he
now has all his patches and other's patches as well, with new unsubmitted
patches on-top of current pnfs. any conflicts were incorporated into the 
new patchset at the affected patches.

Now lets say he has a new patch for the session branch
benny is doing:
# git-checkout -b sessions-todo-buggfix7 origin/sessions
edit, git-commit, git-format-patch, send it upstream.

The pnfs git-tree monkey will need to do:
[C]
# git-checkout sessions
# git-am from-benny-sesions-buggfix7.patch
# git-checkout pnfs
[optional rename here see below]
# git-rebase sessions
So pnfs is kept derived linearly from sessions at all times.

Optionally before the rebase he can do:
# git-branch -m pnfs pnfs-before-buggfix7
# git-checkout -b pnfs
and now do rebase above. So you keep a copy of old pnfs at pnfs-before-buggfix7

Benny and all other developers will do [A] above and optionally [B] for
their work in progress.

Now comes time to update to Linus 2.6.25, lets say. The Monkey at pnfs-tree
is doing (I repeat for clarity):
# git-checkout master
# git-pull
# git-branch -m pnfs pnfs-2.6.24
# git-checkout -b pnfs pnfs-2.6.24
# git-branch -m sessions sessions-2.6.24
# git-checkout -b sessions sessions-2.6.24
# git-rebase master
fix any conflicting patches as they are committed
# git-checkout pnfs
# git-rebase sessions
fix any conflicting patches as they are committed

Voila we have current set of patches for 2.6.25 (we also have
a frozen set for 2.6.24 at branch pnfs-2.6.24)

All users of the tree will do [A] and if needed [B] above
to continue where they left off but on top of 2.6.25 kernel.
Since master is kept clean, [A] will never have problems, even
though upstream tree was rebased to death. All local work should
be done in small, one task, branches that can be easily rebased,
if needed, and abandoned as soon as work is done, to go do new
work on-top of latest upstream pnfs.
(with out saying ALL submitted work should be after rebase to 
the latest upstream pnfs)

OK and one last work-pattern for today.
Now lets say Benny inspects session branch and reviews it
for inclusion into mainline. He finds that patch 50 and 52
of the 100/100 patchset are not good enough. His work he
has done on a local branch. He can do 2 things send incremental
patches to patch50 and patch52, and instruct the Monkey to squash
them in where needed, The Monkey will have to rebase--interactive 
to patch 50:
# git-checkout sessions
# git-rebase--interactive commit-of-patch-50^
He will now get at the editor a list of patches from 50-100
 pick patch 50
 pick patch 51
 pick patch 52
 pick patch 53

he can than change it to:
 edit patch 50
 pick patch 51
 edit patch 52
 pick patch 53

when prompt to edit patch 50 he will:
# patch -p 1 < from-benny-squash-into-patch50.patch
# git-commit -a --amend
# git-rebase --continue
same thing with patch 52. finish the rebase and off course
do not forget the rebase of the pnfs branch

Or If the fixes to patch 50 cause massive un-patch-ability
to lots of patches from 52-100 Benny can send the all set
and Monkey will reset--hard to patch50 and git-am the patchset.
Or Benny can put his new session branch on a public git-tree
and Monkey will do:
# git-branch -m sessions sessions-before-benney-review
# git-checkout -b sessions master
# git-pull git://git.bhalevy.com/pnfs new-sessions
And rebase pnfs to the new sessions tree

If I have missed any work patterns please tell me
And I'll try to help.

Also above shows the work of 2-stage mainline submission.
Maybe you will want to submit it in more stages, then divide
up the chain to more branches linearly stacked on each other.
Also if you need to divide the work to "client" and "server" 
patchsets then that can be done but a bit different then above.

Bruce ??

Boaz