![]() | ||||||||||
Messages in this thread |
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 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/ | |||||||||
| Last update: 2008-02-12 17:35 [from the cache] ©2003-2008 | ||||||||||