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

[Ricardo Labiaga]

So you're proposing to take the same content of linux-pnfs-2.6-latest
and basically generate a set of patches to keeps moving forward?

I don't yet understand git well enough, but I've heard that git-rebase
is the wrong thing to use when you're sharing the repository with
others.  As I understood it, every rebase loses your history and messes
up those who have cloned from you.  Did I misunderstand?

- ricardo


On Tue, 2007-12-04 at 01:19 +0200, Benny Halevy wrote:
> 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