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

[J. Bruce Fields]

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.