David Miller wrote:
I rebase my tree all the time, at least once or twice per
week. Why?
Firstly, to remove crap. When you have "great idea A" then "oh shit A
won't work, revert that" there is zero sense in keeping both
changesets around.
Secondly, I want to fix up the rejects caused by conflicts with
upstream bug fixes and the like (and there are tons when the tree gets
to 1500 or so patches like the networking did). I don't want git to
merge the thing by hand, I want to see what the conflict is and make
sure the "obvious" resolution is OK and the most efficient way I know
how to do that is to suck my tree apart as patches, then suck them
back into a fresh tree.
FWIW, that is annoying and painful for us downstream jobbers, since it
isn't really how git was meant to be used. You use it more like a patch
queue, where commits are very fluid.
Unfortunately, if there is any synchronization lag between me and you --
not uncommon -- then I cannot commit changes on top of the changes just
sent, in my own local tree. Why? Because you rebase so often, I cannot
even locally commit dependent patches due to the end result merge
getting so nasty.
I understand the desire to want a nice and clean history, but the
frequency here really has a negative impact on your downstreams.
It also totally screws the commit statistics, wiping me and John and the
committers we have preserved out, replacing everybody's committer with
David Miller.
Jeff
--
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/
