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

[Ricardo Labiaga]

Thank you Boaz for the extensive example, and thank you Bruce for
commenting on it.  It makes Benny's proposal clearer.  Still need to
experiment with it to really understand it :-)

- ricardo


On Wed, 2007-12-05 at 00:12 -0500, J. Bruce Fields wrote:
> On Tue, Dec 04, 2007 at 03:20:03PM +0200, Boaz Harrosh wrote:
> > 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. 
> 
> There's no real need to do that.
> 
> > (All the trouble with master is that it is a local branch that tries to 
> > stick/float to the origin/master
> 
> There's not really any special relationship between origin/master and
> 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.
> 
> Right.
> 
> > 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.
> 
> If you want, though I think you may as well just use origin/master
> instead of master in the following.
> 
> > 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.
> 
> Sure.
> 
> > 
> > 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.
> 
> Sure.  A slightly trickier case is if some of the patches were changed a
> little bit before being applied, or if earlier patches in pnfs were
> modified.  He may want to do something like
> 
> 	git rebase --onto origin/pnfs <old origin/pnfs> mypnfs-todo-draftXX
> 
> (where <old origin/pnfs> is the commit id of the old tip of origin/pnfs
> that mypnfs-todo-draftXX is based on.  You could tag that commit id to
> help you remember, but I'd probably just fire up
> 
> 	gitk origin..mypnfs-todo-draftXX
> 
> and look for the commit, and then cut-and-paste the commit id.  It's
> pretty quick.)
> 
> > 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.
> 
> Sure, that'll work.
> 
> > 
> > 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
> 
> Yup.  Though like I say I'd probably do
> 
> 	git tag pnfs-before-buggfix7 pnfs
> 
> instead--branches are for things that you expect to keep changing, tags
> are generally for things like this that you expect to stay fixed.
> 
> > 
> > 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
> 
> I'd make those all git-tag's too.
> 
> > # git-rebase master
> 
> And actually instead of
> 
> 	git pull
> 	git rebase master
> 
> I think it'd be simpler just to do
> 
> 	git fetch
> 	git rebase origin/master
> 
> But it amounts to the same thing.
> 
> > 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)
> 
> Yup.
> 
> > 
> > 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
> 
> That looks right.
> 
> > 
> > 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
> 
> I'd actually advise
> 
> 	git remote add benny git://git.bhalevy.com/pnfs
> 	git fetch benny
> 
> And then benny's branches will all appear under benny/<name-of-branch>
> and you can rebase onto them or whatever.
> 
> the git-remote stuff is very useful; together with git fetch it gives
> you a way of keeping a cached view of all the branches in any number of
> different repositories that you're interested in.
> 
> (And note that "origin" isn't special here really--it's just another
> git remote.  In fact you can do the more or less the equivalent of "git
> clone git://example.com/project.git with
> 
> 	mkdir project
> 	cd project
> 	git remote add origin git://example.com/project.git
> 	git fetch origin
> 	git checkout -b master origin/master
> 
> ).
> 
> > 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.
> 
> Sure.
> 
> --b.
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs