| 1 |
On 25 February 2016 at 21:02, Consus <consus@×××.com> wrote: |
| 2 |
> Well, we do have one |
| 3 |
> |
| 4 |
> https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl |
| 5 |
> |
| 6 |
> I bet folks want to check out what's new in their local copy of Portage |
| 7 |
> tree. |
| 8 |
|
| 9 |
|
| 10 |
With a custom, portage oriented, on-demand log generator you could |
| 11 |
produce a lot more detail ( and in a text format that doesn't require |
| 12 |
a web browser to view ) , and potentially use understanding of portage |
| 13 |
conventions to generate change data outside those explicitly stated. |
| 14 |
|
| 15 |
Though that would be a "later feature" you could potentially bolt on |
| 16 |
after the main logic was sorted out. |
| 17 |
|
| 18 |
The idea being you could request a changelog for a package with a list |
| 19 |
of "interest aspects" and have the log reduced to changes that affect |
| 20 |
those interests. |
| 21 |
|
| 22 |
For instance, you could do : |
| 23 |
|
| 24 |
curl http://thing.gentoo.org/changes/dev-lang/perl?arch=~x86 |
| 25 |
|
| 26 |
And with a bit of effort, you could generate a changelog that is only |
| 27 |
relevant for somebody who is on ~x86, eliding changes that x86 didn't |
| 28 |
get yet. |
| 29 |
|
| 30 |
For instance, an ~x86 filter would elide stabilizations for ~x86, |
| 31 |
because you don't care about stabilizations if you're assuming ~arch. |
| 32 |
( And it would elide changes that were only visible for other arches ) |
| 33 |
|
| 34 |
And this filter wouldn't necessarily be implemented in "grep for |
| 35 |
keywords in the commit message", but *analyse the change in the |
| 36 |
directory* based, which would give the ability to do things that would |
| 37 |
otherwise only be possible with a git clone. |
| 38 |
|
| 39 |
|
| 40 |
|
| 41 |
-- |
| 42 |
Kent |
| 43 |
|
| 44 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives