On Thu, May 26, 2016 at 2:46 PM, Sage Weil <sweil@xxxxxxxxxx> wrote:
>
> One point of clarification, though: in the past I've squashed down fixes
> discovered during testing if the branch hasn't hit a stable tree yet
> (e.g., your tree). AIUI this is(was?) standard procedure for things in
> -next.
Yes, rebasing with good reason is acceptable for branches that don't
have anybody else depend on them.
Adn the "good reason" ends up being a judgement call. If the merge
window hasn't even started yet, the "good" reason may not even be very
great, and might might be "oh, I screwed up the commit message, so
let's make the history look good".
If it's already inside the merge window, you should aim for having
increasingly higher barriers to rebasing your tree, and strive to
generally try to avoid it.
If it's about something mostly cosmetic and the merge windoe has
opened or is just about to, leave it be.
On the other hand, if it's really nasty problem and seriously will
hurt people who try to bisect - even if you have fixed the problem
then later in the history - you might choose to do it to not be in the
situation that people who use "git bisect" to find another bug will
then be left with data corruption or something like that because of a
major bug in the middle of the development history.
And in between those two extremes of "cosmetic" and "nasty data
corruption bug" there is obviously a graduation of issues. There can't
be any completely black-and-white rules.
But the corollary to that is that if you really had a major bug that
you feld had to be fixed not just at the tip, but going back, then you
then shouldn't immediately send the end result to me. Because you just
fixed something critical (by definition, if you chose to do it just
before you would have wanted to send to me), so now you need to retest
things.
So rebasing isn't some absolute wrong thing. Sometimes rebasing is
simply the right thing to do. For example, maybe I don't get the same
commits that were in -next, but I would have still seen that the code
was there.
Linus
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
