Mailing List Archive

Git change logs
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.
Re: Git change logs [ In reply to ]
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
Re: Git change logs [ In reply to ]
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>.
Re: Git change logs [ In reply to ]
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
Re: Git change logs [ In reply to ]
On Monday, 29 November 2021 10:39:15 GMT tastytea 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

That's the one I didn't try, of course. Thank you kind sir.

--
Regards,
Peter.
Re: Git change logs [ In reply to ]
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.
Re: Git change logs [ In reply to ]
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
Re: Git change logs [ In reply to ]
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.
Re: Git change logs [ In reply to ]
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