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

[William A. (Andy) Adamson]

On 12/2/07, Halevy, Benny <bhalevy at panasas.com> wrote:
>
> On Nov. 30, 2007, 21:50 +0200, Ricardo Labiaga <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?  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 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?

-->Andy

Also, I plan to try to reorder the sessions patches before the pnfs patches
> to see how easy (or hard) it is to separate them into a different branch in
> preparation to pushing them upstream first.
>
> The key message again is to rebase, not merge. Otherwise it is a nightmare
> to maintain the patches when important stuff gets into merge commits while
> it must belong to the patchset we're working on.
>
> Benny
>
>
>
> >
> > - ricardo
> >
> >
> > On Fri, 2007-11-30 at 14:40 -0500, J. Bruce Fields wrote:
> >> On Fri, Nov 30, 2007 at 01:39:02PM -0500, William A. (Andy) Adamson
> wrote:
> >>> Hi Marc
> >>>
> >>> Last pNFS telecon, you asked if there was a git tree that you could
> clone
> >>> rather than having to apply patches from email. Bruce showed me how to
> add a
> >>> branch to the my public tree (the 2.6.18.3 tree).
> >>>
> >>> so this tree:  git://linux-nfs.org/pub/linux/linux-pnfs.git now
> contains a
> >>> branch called pnfs-client-read-11-30-2007.
> >>>
> >>> so, in the git://linux-nfs.org/pub/linux/linux-pnfs.git tree
> >>>
> >>> 1) git fetch
> >>> 2) git checkout origin/pnfs-client-read-11-30-2007
> >> Note actually there's no need to clone a new tree from linux-pnfs.gitif
> >> you don't already have one.  Just cd into any existing linux repo that
> >> you have, and run
> >>
> >>      git remote add andros-pnfs git://linux-
> nfs.org/pub/linux/linux-pnfs.git
> >>      git fetch andros-pnfs
> >>      git checkout andros-pnfs/pnfs-client-read-11-30-2007
> >>
> >> (The name "andros-pnfs" is arbitrary--you can use whatever name you
> >> like.)
> >>
> >> --b.
> >> _______________________________________________
>
>
>
>
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20071203/1b029c2f/attachment.htm