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

[Benny Halevy]

William A. (Andy) Adamson wrote:
>
>
> On 12/2/07, *Halevy, Benny* <bhalevy at panasas.com 
> <mailto:bhalevy at panasas.com>> wrote:
>
>     On Nov. 30, 2007, 21:50 +0200, Ricardo Labiaga
>     <ricardo.labiaga at netapp.com <mailto:ricardo.labiaga at netapp.com>>
>     wrote:
>     > On a related note, do people prefer to move the 2.6-latest work
>     into a
>     > branch of git://linux- nfs.org/pub/linux/linux-pnfs.git
>     <http://nfs.org/pub/linux/linux-pnfs.git>?  Instead of
>     > having it as a separate tree?
>
>     I like this idea in general providing the master branch will contain
>     a cleanly integrated version of the code ( i.e. we need to move the
>     2.6.18.3 <http://2.6.18.3> work to a sub-branch derived from the
>     v2.6.18.3 tag or a similar
>     common ancestor.
>
>     From my experience, the general guidelines should be that branches
>     should
>     be used to stage feature work that might not be ready to be pushed
>     upstream
>     towards the master branch or that we want to keep separate.  Then,
>     pulling
>     the master branch into the feature branch should be done with
>     git-rebase,
>     not git-merge, and the patches should be reworked each time you do
>     that to
>     keep them in sync with the master branch.  If you do this in
>     relatively small
>     increments the effort should pay off.
>
>
>     I've started working on rebasing the current patches in
>     linux-pnfs-latest on top of linus's tree so that the merge
>     conflict fixes will get integrated properly into the patchset and
>     to float it on top of the linux tree.  
>
>
> isn't this what ricardo has already done with linux-pnfs-2.6-latest?
>
Unfortunately, what's currently in linux-pnfs-latest contains some 
pretty major changes and even
bug fixes in merge commits done when the mainline kernel was merged into 
the tree.
This is absolutely wrong as these details must find their way into each 
particular patch via git-rebase
(or to additional patches if need be) so that the patchset will be 
submittable to the mainline kernel
after the merge.  The idea is to keep the patchset current so it will do 
the same thing just in the new world,
post the rebase.  For example take Christoph Hellwig's changes moving 
the export operations from fs.h
to exportfs.h.  They affect our patches that add export operations.  
Currently the original patches are left
committed in the tree and the merge commit moves the definition from one 
header file to the other, but
the original patch is useless in the new world.  By rebasing the old 
patch on top of the new kernel
it is morphed into the new world and the new ops are added at the right 
spot making the revised version
of the patch current and submittable in the new world.  (If you're 
worried about losing track of
the original patches then they still exist and reachable in the git tree 
although they don't show up
in git-log...)

Benny
> -->Andy