1 |
On Mon, Nov 29, 2021 at 11:43 AM Peter Humphrey <peter@××××××××××××.uk> wrote: |
2 |
> |
3 |
> On Monday, 29 November 2021 16:32:45 GMT Rich Freeman wrote: |
4 |
> > On Mon, Nov 29, 2021 at 11:17 AM Peter Humphrey |
5 |
> <peter@××××××××××××.uk> wrote: |
6 |
> > > # (cd /var/db/repos/gentoo/sys-devel/gcc && git whatchanged) |
7 |
> > |
8 |
> > You'd get just as much output from git log - you didn't restrict the |
9 |
> > output so it ran on the entire repository. The current working |
10 |
> > directory has no impact on the function of either git log or git |
11 |
> > whatchanged. |
12 |
> |
13 |
> See what I mean about counter-intuitive? |
14 |
|
15 |
You won't get any arguments from me that git is not a very refined |
16 |
piece of software. The other glaring flaw is inconsistencies in |
17 |
command line options between various subcommands. |
18 |
|
19 |
It is a beautiful concept, with a rough implementation. |
20 |
|
21 |
> |
22 |
> > You could append a . to just run git whatchanged on the current |
23 |
> > directory. I run "git whatchanged ." all the time. |
24 |
> |
25 |
> Thanks. I will. But how do I find the real change log of a package? The sort of |
26 |
> stuff I used to include in a software release bulletin when I was running the |
27 |
> show. What has changed, and why? What fault reports have been closed? What |
28 |
> new behaviour can be expected? |
29 |
|
30 |
If there are any gentoo bugs resolved by a commit they're likely to |
31 |
show up in the log (or with whatchanged), unless you ask for a oneline |
32 |
version which will only show the first line of the log. The bugs |
33 |
would include links but obviously you'd have to hunt down what they |
34 |
actually are. |
35 |
|
36 |
Usually if a commit fixes some sort of serious issue it is going to |
37 |
end up in the text of the commit description, especially if that were |
38 |
the only change. If it is a version bump and it happened to also |
39 |
update the EAPI or fix a URL or something minor that might not get |
40 |
mentioned. |
41 |
|
42 |
As far as upstream behavior changes goes, don't expect to see this in |
43 |
the commit log unless it is incredibly impactful, in which case you |
44 |
might get news (like some big ABI break in the toolchain or |
45 |
something). In general Gentoo does not really do handholding with |
46 |
release notes with upstream changes, or even provide more than a basic |
47 |
level of integration across packages. As was mentioned in another |
48 |
recent discussion, don't expect that the latest stable kernel is |
49 |
guaranteed to work with the latest stable zfs-kmod package, etc. A |
50 |
more release-based distro would be better equipped to do that but |
51 |
actually doing a serious job of upstream release notes would be a LOT |
52 |
of work. |
53 |
|
54 |
The Gentoo commit log is going to be more about changes in how |
55 |
something is packaged. Some are more detailed than others. I know I |
56 |
personally try to mention things like EAPI changes but I'm not sure |
57 |
that everybody does. |
58 |
|
59 |
Unfortunately since most changes create new revisions the diff |
60 |
capabilities of git tend to be limited in usefulness. |
61 |
|
62 |
-- |
63 |
Rich |