lkml.org 
[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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




\
 
 \ /
  Last update: 2008-02-12 17:35    [W:0.785 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site