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

J. Bruce Fields bfields at fieldses.org
Mon Dec 3 22:57:47 EST 2007


On Mon, Dec 03, 2007 at 07:21:42PM -0800, Ricardo Labiaga wrote:
> 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?

Well, it's a tradeoff.  You're essentially restarting the history from
scratch each time.  That means for example if someone else is building
work on top of your work, then they have to manually figure out where
their series ended and your patches began in order to port them forward
to a new version of your branch.

Also unless you take extra steps to save old versions of the patch
series you may have trouble, e.g., identifying regressions from one to
the next.

But, OK, given the troubles merges seem to be causing, Benny's probably
right.

(What I've actually started doing is both! I rebase each time, *and*
also stick a merge commit on top to connect the new version of the
series with the old.  So the first parent of the most recent commit
always points to the latest version of the series, and the second to the
history of the series.  Of course, I just submit that first parent, as
upstream doesn't want to see all the old series versions.  But this is a
little complicated to set up....)

--b.


More information about the pNFS mailing list