On 08/24/2011 01:02 AM, Nirbheek Chauhan wrote:
> On Wed, Aug 24, 2011 at 12:28 PM, Fabian Groffen <email@example.com> wrote:
>> On 24-08-2011 00:44:57 -0400, Matt Turner wrote:
>>> On Tue, Aug 23, 2011 at 10:30 PM, Donnie Berkholz <firstname.lastname@example.org> wrote:
>>>> On 15:49 Tue 23 Aug , Lance Albertson wrote:
>>>>> I think using the shortlog output is the sane solution otherwise you're
>>>>> just replicating what you do in the commit.
>>>> It's not replication if users continue to use rsync; they won't have
>>>> commit info.
>>> Do we really want users to continue using rsync? Isn't git pull so
>>> much faster? What's the downside of users using git directly?
>> ehm, that you need git? that you need to use git to get information
>> about changes? that you need a whole new infrastructure of mirrors to
>> get it running (vs the rsync infrastructure)? that you need at minimum
>> 800MiB to be able to look at some history, iso. 286MiB as the rsync tree
>> is now?
>> Besides from that git doesn't even work on all platforms, but I can
>> imagine you don't care about that.
> Actually, the major blocker as I understand it, is portage metadata
> cache regeneration.
If anybody needs some background information on this, the "[RFC] DIGESTS
metadata variable for cache validation" thread can serve as a useful
Also, note that it's possible to use post-sync scripts to tweak mtimes
of files pulled with git:
We've had support for git post-sync timestamp handling in emerge for
some time now: