lkml.org 
[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 12 Feb 2008 11:31:48 -0500
FromJeff Garzik <>
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


--
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