On 2021-11-29 10:26+0000 Peter Humphrey <peter@prh.myzen.co.uk> wrote:

Hello list,

Today's update includes sys-devel/gcc-11.2.1_p20211127, up from
11.2.1. I wanted to find out what changes had been introduced, so I
went searching for the change log. I sync gentoo with git, so it
should be easy to find the log. Google found references to git log,
but when I tried it I got this:

/var/db/repos/gentoo # git log sys-devel/gcc-11.2.1_p20211127
fatal: ambiguous argument 'sys-devel/gcc-11.2.1_p20211127': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

So I did that, but whatever I tried returned 'bad revision'. What's
the proper syntax?

If you want the history for a file, you need to specify the full path:

git log sys-devel/gcc/gcc-11.2.1_p20211127.ebuild

Kind regards, tastytea

--
Get my PGP key with `gpg --locate-keys tastytea@tastytea.de` or at <https://tastytea.de/tastytea.asc>.

-----BEGIN PGP SIGNATURE-----

iHUEAREKAB0WIQQ1VSZoZMptf/RapufPw5SX8bJuBwUCYaSt0wAKCRDPw5SX8bJu BwkHAP0R2uC5SSvE6RMSBNI1+xJh6YYJEeHB6OPdJN6FblqqtAD/XSNmBsM8YNeB dTTNRP6O9luUZM9r7/4+lPXw3Srut0Q=
=bxTn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello list,

Today's update includes sys-devel/gcc-11.2.1_p20211127, up from 11.2.1. I wanted to find out what changes had been introduced, so I went searching for the change log. I sync gentoo with git, so it should be easy to find the log. Google found references to git log, but when I tried it I got this:

/var/db/repos/gentoo # git log sys-devel/gcc-11.2.1_p20211127
fatal: ambiguous argument 'sys-devel/gcc-11.2.1_p20211127': unknown revision
or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

So I did that, but whatever I tried returned 'bad revision'. What's the proper syntax?

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 29 Nov 2021 at 11:26, Peter Humphrey <peter@prh.myzen.co.uk> wrote:

/var/db/repos/gentoo # git log sys-devel/gcc-11.2.1_p20211127
fatal: ambiguous argument 'sys-devel/gcc-11.2.1_p20211127': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

So I did that, but whatever I tried returned 'bad revision'. What's the proper
syntax?

It lists the syntax right there. I don't sync with git, so I can't
check this with my repo, but it seems like you need to refer to an
actual path or file, so one of these:
$ git log sys-devel/gcc
$ git log sys-devel/gcc/gcc-11.2.1_p20211127.ebuild

Regards,
Arve

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Nov 29, 2021 at 5:39 AM tastytea <gentoo@tastytea.de> wrote:

If you want the history for a file, you need to specify the full path:

git log sys-devel/gcc/gcc-11.2.1_p20211127.ebuild

You can also point it at a directory and get changes for the entire
directory. I also suggest trying "git whatchanged" as an alternative
to "git log." I'm guessing you could get git log to display the same
info but I find whatchanged to be more useful, at least for
directories. There wouldn't be much point in running it on a single
file since the main benefit is showing what files changed in each
commit.

Keep in mind that git knows nothing about gentoo package atoms/syntax.
It just sees a directory tree and files...

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 29 November 2021 16:03:25 GMT Rich Freeman wrote:

On Mon, Nov 29, 2021 at 5:39 AM tastytea <gentoo@tastytea.de> wrote:

If you want the history for a file, you need to specify the full path:

git log sys-devel/gcc/gcc-11.2.1_p20211127.ebuild

You can also point it at a directory and get changes for the entire directory. I also suggest trying "git whatchanged" as an alternative
to "git log."

I didn't know about whatchanged. I tried it like this and got 120k lines of output:

# (cd /var/db/repos/gentoo/sys-devel/gcc && git whatchanged)

I've always found git counter-intuitive and I've resisted trying to understand it, so far. Maybe I should make a little more effort.

I'm guessing you could get git log to display the same
info but I find whatchanged to be more useful, at least for
directories. There wouldn't be much point in running it on a single
file since the main benefit is showing what files changed in each
commit.

Keep in mind that git knows nothing about gentoo package atoms/syntax.
It just sees a directory tree and files...

Yes, I did know that.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Nov 29, 2021 at 11:17 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:

On Monday, 29 November 2021 16:03:25 GMT Rich Freeman wrote:

On Mon, Nov 29, 2021 at 5:39 AM tastytea <gentoo@tastytea.de> wrote:

If you want the history for a file, you need to specify the full path:

git log sys-devel/gcc/gcc-11.2.1_p20211127.ebuild

You can also point it at a directory and get changes for the entire directory. I also suggest trying "git whatchanged" as an alternative
to "git log."

I didn't know about whatchanged. I tried it like this and got 120k lines of output:

# (cd /var/db/repos/gentoo/sys-devel/gcc && git whatchanged)

You'd get just as much output from git log - you didn't restrict the
output so it ran on the entire repository. The current working
directory has no impact on the function of either git log or git
whatchanged.

You could append a . to just run git whatchanged on the current
directory. I run "git whatchanged ." all the time.

I've always found git counter-intuitive and I've resisted trying to understand
it, so far. Maybe I should make a little more effort.

IMO time spent understanding git is highly rewarded. It isn't going anywhere.

I've heard it said that git is a data model masquerading as an SCM,
and that is very accurate. If you don't understand how it works
you're going to be fighting it.

I get that you shouldn't have to know how the data model works to use
a piece of software, but git runs pretty close to the metal. Sure,
you can always just copy/paste some one-liner that you read on a
website, but you're always going to feel like you're wrestling it.
Linus basically built it for himself and a handful of people like him,
and it shows. It is very powerful, but it is a bit like trying to use
binutils without wanting to know what an ELF is.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 29 November 2021 16:32:45 GMT Rich Freeman wrote:

On Mon, Nov 29, 2021 at 11:17 AM Peter Humphrey

<peter@prh.myzen.co.uk> wrote:

# (cd /var/db/repos/gentoo/sys-devel/gcc && git whatchanged)

You'd get just as much output from git log - you didn't restrict the
output so it ran on the entire repository. The current working
directory has no impact on the function of either git log or git
whatchanged.

See what I mean about counter-intuitive?

You could append a . to just run git whatchanged on the current
directory. I run "git whatchanged ." all the time.

Thanks. I will. But how do I find the real change log of a package? The sort of stuff I used to include in a software release bulletin when I was running the show. What has changed, and why? What fault reports have been closed? What
new behaviour can be expected?

I've always found git counter-intuitive and I've resisted trying to understand it, so far. Maybe I should make a little more effort.

IMO time spent understanding git is highly rewarded. It isn't going anywhere.

I've heard it said that git is a data model masquerading as an SCM,
and that is very accurate. If you don't understand how it works
you're going to be fighting it.

I get that you shouldn't have to know how the data model works to use
a piece of software, but git runs pretty close to the metal. Sure,
you can always just copy/paste some one-liner that you read on a
website, but you're always going to feel like you're wrestling it.
Linus basically built it for himself and a handful of people like him,
and it shows. It is very powerful, but it is a bit like trying to use binutils without wanting to know what an ELF is.

:)

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Nov 29, 2021 at 11:43 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:

On Monday, 29 November 2021 16:32:45 GMT Rich Freeman wrote:

On Mon, Nov 29, 2021 at 11:17 AM Peter Humphrey

<peter@prh.myzen.co.uk> wrote:

# (cd /var/db/repos/gentoo/sys-devel/gcc && git whatchanged)

You'd get just as much output from git log - you didn't restrict the
output so it ran on the entire repository. The current working
directory has no impact on the function of either git log or git whatchanged.

See what I mean about counter-intuitive?

You won't get any arguments from me that git is not a very refined
piece of software. The other glaring flaw is inconsistencies in
command line options between various subcommands.

It is a beautiful concept, with a rough implementation.

You could append a . to just run git whatchanged on the current
directory. I run "git whatchanged ." all the time.

Thanks. I will. But how do I find the real change log of a package? The sort of
stuff I used to include in a software release bulletin when I was running the show. What has changed, and why? What fault reports have been closed? What new behaviour can be expected?

If there are any gentoo bugs resolved by a commit they're likely to
show up in the log (or with whatchanged), unless you ask for a oneline
version which will only show the first line of the log. The bugs
would include links but obviously you'd have to hunt down what they
actually are.

Usually if a commit fixes some sort of serious issue it is going to
end up in the text of the commit description, especially if that were
the only change. If it is a version bump and it happened to also
update the EAPI or fix a URL or something minor that might not get
mentioned.

As far as upstream behavior changes goes, don't expect to see this in
the commit log unless it is incredibly impactful, in which case you
might get news (like some big ABI break in the toolchain or
something). In general Gentoo does not really do handholding with
release notes with upstream changes, or even provide more than a basic
level of integration across packages. As was mentioned in another
recent discussion, don't expect that the latest stable kernel is
guaranteed to work with the latest stable zfs-kmod package, etc. A
more release-based distro would be better equipped to do that but
actually doing a serious job of upstream release notes would be a LOT
of work.

The Gentoo commit log is going to be more about changes in how
something is packaged. Some are more detailed than others. I know I personally try to mention things like EAPI changes but I'm not sure
that everybody does.

Unfortunately since most changes create new revisions the diff
capabilities of git tend to be limited in usefulness.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)