David Miller wrote:
quoted text
> 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


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/