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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
