[pnfs] [PATCH 0/14] linux-pnfs-2.6-latest pNFS client read I/O - Draft 13

[J. Bruce Fields]

On Thu, Nov 15, 2007 at 01:12:32PM +0200, Benny Halevy wrote:
> Anyhow, this is a good example why having a thorough process for porting
> the patches is so important.  Making changes in the porting process is
> inevitable since the environment changed (a lot), however changing the
> functionality and/or fixing bugs (or what we think are bugs) in the
> process is quite risky.
> 
> I tried pulling the changes from linux-pnfs to linux-pnfs-2.6
> in order to establish a depot for the patches we they can be manipulated
> more easily in git by resetting a branch in linux-pnfs-2.6 to v2.6.18
> which is a common ancestor of both trees. This went ok, but attempting
> to rebase the patchset onto a more recent point went horribly wrong.

I would've tried doing a merge (first of the sessions branch, then of
the pnfs branch) instead of rebasing.  So something like

	git checkout -b new-sessions v2.6.24-rc2
	git merge old-pnfs
	# resolve conflicts...
	git commit
	git checkout -b new-pnfs new-sessions
	git merge old-sessions
	# resolve conflicts...
	git comit

Though honestly the merge is likely to be really painful at this
point--there are so many changes on both side (especially the upstream
side) that the conflicts are going to be huge, and very complicated to
sort out.  You could might be able to keep that under control by merging
one upstream version at a time (first merge with v2.6.19, then v2.6.20,
etc.--or possibly at even finer intervals).

> Basically every merge point in which sessions patches were pushed to
> the master branch presented conflicts when trying to do the rebase and
> the merge has to be replayed (and since we didn't enabled rerere there
> doesn't seem to be an easy way to do that since git-show of the merge
> commit is insufficient to resolve the merge conflict.  Is there
> an easy way to do this with git that I'm not aware of?

I've never actually tried to rebase merge commits.

> After discussing this with Boaz we came to the conclusion that
> using rebase rather than merge should do a better job in integrating
> the pnfs patches on top of the sessions patches as the each committed
> patch after the rebase will be in sync with the branch so I'm going to
> retry this by applying the sessions patches onto a 2.6.18.3 branch 
> (off of linux-pnfs-2.6) and having a sub-branch of that for the pnfs-patches
> which I'll rebase at the merge points we have in the 2.6.18.3 tree so that
> we'll have a coherent set of patches to play with.

OK, apologies, I think I'm at fault for suggesting the current merging
strategy.  You may well be right that it'd be easier just to rebase each
time.

I think the important thing is to update really frequently.  I just
don't see how it's going to be possible to do careful incremental
development when you're trying to update everything across multiple
kernel versions at once.

--b.