linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080212193754.GC18625@fieldses.org>
Date:	Tue, 12 Feb 2008 14:37:54 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	John Linville <linville@...driver.com>
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, Feb 12, 2008 at 11:31:48AM -0500, Jeff Garzik wrote:
> 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.

But the "author" is still preserved, right?  Why do you need the
committer name to be preserved?  (I'm not denying that there could be
reasons, I'm just curious what they are.)

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