Messages in this thread | | | Date | Tue, 12 Feb 2008 11:31:48 -0500 | From | Jeff Garzik <> | Subject | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| |
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
| |