On Feb. 12, 2008, 20:36 +0200, Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
> 
> On Tue, 12 Feb 2008, Benny Halevy wrote:
>> IMHO, this base tree should typically be based off of linus' tree
>> and kept rebased on top of it.  This way you get the mainline fixes
>> through the integration base tree.
> 
> Hell no!
> 
> No rebasing! If people rebase, then it's useless as a base.

Linus, what you're saying is pretty extreme.

Our experience with pnfs development taught us that rebase was actually the only
method that worked on the long run because it allows us to maintain a *clean* series of
patchsets over an extended period of time (order of two years).

In the past, when we merged your tree into ours rather than using git-remote update and
rebase we ended up with a cluttered mess that buried all the resolved merge conflicts
in merge commits and maintaining it became an increasingly harder nightmare.

Nowadays, I rebase the linux-pnfs git tree almost on a daily basis, keeping tags
on historical refs (to be cleaned up when a branch stabilizes) and the other
contributors simply use git-remote update to refresh their tracking branches and
rebase their stuff onto the new heads.  It took the team a couple weeks to get used
to this methodology but it really works great for us now.

It seems to me that merging works well one (your :) way when patches are merged
upstream and become immutable at this point, while on the other way, keeping
a patchset fresh and comprehensible is feasible only with rebase when there
are occasional conflicts with stuff coming down from upstream.  The domino-
effect caused by rebase is manageable and not worse than merge if people
just keep track of the original bases of their development branch before
updating their tracking branches.

Maybe the missing link is a tool to help do rebasing more easily.
I wrote my own tool for that: git-rebase-tree (available on
git://git.bhalevy.com/git-tools.git) and using it makes the mechanics
of rebasing our patchsets almost trivial.  I really encourage folks
to try it out and give me feedback about it.

Benny

quoted text
> 
> That base tree needs to be something people can *depend* on. It contains 
> the API changes, and not anything else. Otherwise I will never ever pull 
> the resulting mess, and you all end up with tons of extra work.
> 
> Just say *no* to rebasing.
> 
> Rebasing is fine for maintaining *your* own patch-set, ie  it is an 
> alternative to using quilt. But it is absolutely not acceptable for 
> *anythign* else. 

So what's the solution for maintaining a series of patchsets that depend
on one another?

quoted text
> 
> In particular, people who rebase other peoples trees should just be shot 
> (*). It's simply not acceptable behaviour. It screws up the sign-off 
> procedure, it screws up the people whose code was merged, and it's just 
> WRONG.
> 
> 			Linus
> 
> (*) The exception being if there is something seriously wrong with the 
> tree. I think I've had trees which I just refused to pull, and while most 
> of the time I just say "I refuse to pull", early on in git development I 
> actually ended up fixing some of those trees up because my refusal was due 
> to people mis-using git in the first place. So I have actually effectively 
> rebased a maintainer tree at least once. But I still think it is seriously 
> screwed up.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/