Re: Announce: Linux-next (Or Andrew's dream :-))

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 12 Feb 2008, J. Bruce Fields wrote:
> 
> But the "author" is still preserved, right?  Why do you need the
> committer name to be preserved?  (I'm not denying that there could be
> reasons, I'm just curious what they are.)

It's not that the committer should be preserved, but:

 - the chain from author -> committer should be visible in the 
   Signed-off-by: lines.

   If you rebase somebody elses tree, you screw that up. You need to add 
   your sign-off, since now *you* are the new committer, and *you* took
   somebody elses work!

 - you should respect the down-stream developer, and if that downstream 
   developer continues to work with his branch or works with other people, 
   you shouldn't screw that up!

Both of those basically say that you should never rebase somebody elses 
work. You can use rebase to rebase your *own* work on top of somebody 
elses thing (since that doesn't change the sign-off chain, and you still 
respect the downstream developers development model)!

But of course, if you rebase, you should respect the wishes of the 
up-stream developer too. I don't do rebases. So if you asked me to pull, 
the stuff I pulled can never be rebased, because it just *is* in my tree. 

Put another way: think of the absolute *chaos* that would happen if I were 
to rebase instead of just merging. Every time I pull from you I'd 
invalidate your whole tree, and you'd have to re-generate. It gets 
unmaintainable very quickly.

And that's actually ignoring a real issue: stability of commits. The nice 
thing about stable commit naming is that all bug-reports from other people 
that told where the bug happened are basically 100% trust-worthy and the 
code is 100% reproducible not just for you, but for everybody else. 

In other words, you really shouldn't rebase stuff that has been exposed 
anywhere outside of your own private tree. But *within* your own private 
tree, and within the commits that have never seen the light of day, 
rebasing is fine.

(And yes, there are exceptions. If it's a clear "throw-away tree" all the 
rules go out the window, of course, as long as everybody involved *knows* 
it's a throw-away tree, and know that if they pull it they have to 
synchronise 100% with you - so within a very tight-knit case or within a 
very specific small detail that is actively being worked on, those rebases 
with cleanups make tons of sense).

			Linus