Luis Ressel wrote:
>
> That would require a local git clone. And that's exactly what those who
> still want Changelogs are trying to avoid.
You need even a deep git clone with full history.
Already now this means that you need 2 (or already 3?) times the
disk space as for an rysnc mirror; multip
On 25 February 2016 at 18:03, Duncan <1i5t5.dun...@cox.net> wrote:
> Which I am (running from the git repo), and that ability to (as a user,
> easily) actually track all that extra data was one of my own biggest
> reasons for so looking forward to the git switch for so long, and is now
> one of the
Kent Fredric posted on Wed, 24 Feb 2016 23:35:57 +1300 as excerpted:
> Though personally I feel for the goal of stabilization tracking, you
> aught to be analysing the git repo. Not only can you then see when a
> given package was stabilised, but you can see the other packages that
> were stabiliz
On Wed, 24 Feb 2016 21:16:13 +0100
Luis Ressel wrote:
> On Wed, 24 Feb 2016 11:18:55 -0800
> Raymond Jennings wrote:
>
> > As far as changelog generation, what about causing the changelogs to
> > be autogenerated by the end user's computer? Divide and conquer.
>
> That would require a local
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/24/2016 12:16 PM, Luis Ressel wrote:
> On Wed, 24 Feb 2016 11:18:55 -0800 Raymond Jennings
> wrote:
>
>> As far as changelog generation, what about causing the changelogs
>> to be autogenerated by the end user's computer? Divide and
>> conqu
On Wed, 24 Feb 2016 11:18:55 -0800
Raymond Jennings wrote:
> As far as changelog generation, what about causing the changelogs to
> be autogenerated by the end user's computer? Divide and conquer.
That would require a local git clone. And that's exactly what those who
still want Changelogs are
Seems like there's a trade off in resource usage re: git vs rsync
Rsync seems to be relatively cheap, but has a fixed part of its overhead.
Probably one of the reasons that you get temp-banned from the mirrors if
you sync too often.
Git overhead appears ot be higher on the variable parts but lowe
On 24 February 2016 at 20:29, Duncan <1i5t5.dun...@cox.net> wrote:
> I guess another way of putting it in the context of changelogs, would be
> that if gentoo were using git merges correctly, a changelog summary
> generator could simply take the high-level merge summary comments and
> turn that int
