[pnfs] Best practices for merging w/ ~bhalevy/linux-pnfs

[J. Bruce Fields]

On Wed, Jan 09, 2008 at 08:55:20AM -0800, Labiaga, Ricardo wrote:
> During our last concall there was mention that we needed to follow a
> somewhat different procedure to resolve conflicts when sync'ing with
> git://linux-nfs.org/~bhalevy/linux-pnfs.  I don't see anything related
> in http://www.citi.umich.edu/projects/asci/pnfs/linux/.
>  
> If I have local changes that have not yet been pushed upstream, and I
> pull from linux-nfs.org, I then have to resolve the conflicts.  Should I
> resolve the conflicts into one large commit, or do I need to spread the
> conflict resolution among my various commits that I have not yet pushed
> upstream?  If the latter, is there a special git-rebase incantation that
> I should use?  How do others deal with this?

Assuming your work is in master, and Benny's is in bhalevy/master:

	git rebase --onto bhalevy/master <base sha1> master

will reapply all the patches between <base sha1> and master onto
bhalevy/master.  So you'll be asked to resolve any conflicts in each
patch as you go, and your master will be left pointing to the result.

I generally figure out what <base sha1> is just by running

	gitk origin..master

and looking.  You want the last commit that is *not* one of yours.
(So, probably what used to be the tip of Benny's branch.)

The conflict-fixing along the way isn't too hard; it'll stop and
complain and when you're done fixing up the conflicts, just

	git add -u
	git rebase --continue

if the result is that the patch is now empty--say because Benny has
applied that patch--then you'll use --skip instead of --continue.
Rebase will remind you about --continue and --skip if you forget.

If you mess up then the "reflog" keeps a record of what you've done (by
default, for a month or so)--"git log -g" will show you.  Or you can
create a tag pointing to the old master before you rebase if that's more
comfortable.

--b.