Can the automatic daily update commits be stopped?

Can the automatic daily update commits be stopped?

[David Howells]

Can the automatic "daily update" and "Automatic date update in version.in"
commits be stopped?  Or at least only performed if the last commit was not
itself such a commit?

As far as I can see, the upsides are:

 (*) Makes CVS easier to manage.

 (*) Daily tarball/patch releases can be made from the daily update commits.

and the downsides are:

 (*) The information displayed by git fetch can't be used tell if there've
     been any changes since yesterday since there has always been at least one
     insignificant automatic change since yesterday.

 (*) Reduces overall git efficiency.

 (*) Increases the likelyhood of getting a hash collision in the git repo.

 (*) Gives git bisect more steps to go through (granted this only increases
     with log2 of N).

 (*) Severely reduces the amount of useful information that can be displayed
     in UIs such as gitweb.

     Take a look at:

	http://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_24-branch

     for example.  Only 7 actual changes are visible on the first page.  93
     "daily update" messages are visible, however.

Would it be possible instead to ask people to make use of the git commit ID
rather than the version date as a reference?  Especially as there can be
multiple changes per date...

Thanks,
David

Re: Can the automatic daily update commits be stopped?

[Fred Cooke]

Amen, big +1, stop the madness.

Re: Can the automatic daily update commits be stopped?

[Joel Brobecker]

> Amen, big +1, stop the madness.

Make it another strong +1. I really don't see the point of having
that date, and it make "git log" really hard to read on the branches.

Instead of using the date, how about we use the SHA1, or else
the output of "git describe". The latter is really nice for
branches, as it contains the number of commits since most
recent tag found on a given branch.

This would be done during the build, using git info if the sources
are under git. For those building from source tarballs, I should
be able to pre-insert that info during the source packaging that
we do nightly (of for the releases).

-- 
Joel

Re: Can the automatic daily update commits be stopped?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> Instead of using the date, how about we use the SHA1, or else
> the output of "git describe".

The latter won't quite work before the release or on master, since there
is no related tag.

$ git describe --tags origin/master
readline_4_0-82304-g533d0af

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can the automatic daily update commits be stopped?

[H.J. Lu]

On Tue, Jan 6, 2015 at 5:08 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Joel Brobecker <brobecker@adacore.com> writes:
>
>> Instead of using the date, how about we use the SHA1, or else
>> the output of "git describe".
>
> The latter won't quite work before the release or on master, since there
> is no related tag.
>
> $ git describe --tags origin/master
> readline_4_0-82304-g533d0af
>

We can use

[hjl@gnu-tools-1 binutils-gdb]$ echo "on $(git name-rev --name-only
HEAD) commit $(git log -1 --pretty=%H)"
on master commit 533d0af0b8a8127b6f189222fc57aa11ce7aab2c
[hjl@gnu-tools-1 binutils-gdb]$

for version.  We add remote git repo URL with

[hjl@gnu-tools-1 binutils-gdb]$ git remote -v | grep fetch | awk '{ print $2}'
ssh://hjl@sourceware.org/git/binutils-gdb.git
[hjl@gnu-tools-1 binutils-gdb]$

-- 
H.J.

Re: Can the automatic daily update commits be stopped?

[Joel Brobecker]

> > Instead of using the date, how about we use the SHA1, or else
> > the output of "git describe".
> 
> The latter won't quite work before the release or on master, since there
> is no related tag.

We can add those tags, if we wanted to. But why not start simple,
indeed, and just use the SHA1?

-- 
Joel

Re: Can the automatic daily update commits be stopped?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

>> > Instead of using the date, how about we use the SHA1, or else
>> > the output of "git describe".
>> 
>> The latter won't quite work before the release or on master, since there
>> is no related tag.
>
> We can add those tags, if we wanted to. But why not start simple,
> indeed, and just use the SHA1?

An SHA1 does not tell you anything without the associated repository.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can the automatic daily update commits be stopped?

[Joel Brobecker]

> > We can add those tags, if we wanted to. But why not start simple,
> > indeed, and just use the SHA1?
> 
> An SHA1 does not tell you anything without the associated repository.

Do you have a suggestion?

-- 
Joel

Re: Can the automatic daily update commits be stopped?

[H.J. Lu]

On Tue, Jan 6, 2015 at 7:13 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > We can add those tags, if we wanted to. But why not start simple,
>> > indeed, and just use the SHA1?
>>
>> An SHA1 does not tell you anything without the associated repository.
>
> Do you have a suggestion?

Try this in binutils-gdb tree:

#  echo "$(git remote -v | grep fetch | awk '{ print $2}') on $(git
name-rev --name-only HEAD) commit $(git log -1 --pretty=%H)"


-- 
H.J.

Re: Can the automatic daily update commits be stopped?

[David Howells]

H.J. Lu <hjl.tools@gmail.com> wrote:

> Try this in binutils-gdb tree:
> 
> #  echo "$(git remote -v | grep fetch | awk '{ print $2}') on $(git
> name-rev --name-only HEAD) commit $(git log -1 --pretty=%H)"

I suspect that what Andreas is getting at is that you can't compare SHA1 sums
to gain any information on the relative age of two commits.

David

Re: Can the automatic daily update commits be stopped?

[H.J. Lu]

On Tue, Jan 6, 2015 at 7:54 AM, David Howells <dhowells@redhat.com> wrote:
> H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> Try this in binutils-gdb tree:
>>
>> #  echo "$(git remote -v | grep fetch | awk '{ print $2}') on $(git
>> name-rev --name-only HEAD) commit $(git log -1 --pretty=%H)"
>
> I suspect that what Andreas is getting at is that you can't compare SHA1 sums
> to gain any information on the relative age of two commits.
>

Why not?  I do it all time.

-- 
H.J.

Re: Can the automatic daily update commits be stopped?

[David Howells]

H.J. Lu <hjl.tools@gmail.com> wrote:

> Why not?  I do it all time.

Without the repo being available, that is.

I also compare SHA1 sums - using the repo frequently, so it's not a problem
for me.

David

Re: Can the automatic daily update commits be stopped?

[H.J. Lu]

On Tue, Jan 6, 2015 at 8:03 AM, David Howells <dhowells@redhat.com> wrote:
> H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> Why not?  I do it all time.
>
> Without the repo being available, that is.
>
> I also compare SHA1 sums - using the repo frequently, so it's not a problem
> for me.
>

Can you tell me what other info you need:

[hjl@gnu-6 binutils-gdb]$ echo "$(git remote -v | grep fetch | awk '{
print $2}') on $(git name-rev --name-only HEAD) commit $(git log -1
--pretty=%H)"
ssh://hjl@sourceware.org/git/binutils-gdb.git on master commit
533d0af0b8a8127b6f189222fc57aa11ce7aab2c
[hjl@gnu-6 binutils-gdb]$

-- 
H.J.

Re: Can the automatic daily update commits be stopped?

[David Howells]

H.J. Lu <hjl.tools@gmail.com> wrote:

> Can you tell me what other info you need:
> 
> [hjl@gnu-6 binutils-gdb]$ echo "$(git remote -v | grep fetch | awk '{
> print $2}') on $(git name-rev --name-only HEAD) commit $(git log -1
> --pretty=%H)"
> ssh://hjl@sourceware.org/git/binutils-gdb.git on master commit
> 533d0af0b8a8127b6f189222fc57aa11ce7aab2c

I would guess Andreas would probably want date at least - but there's still
the problem of multiple commits within a day.  Even within a single second, I
would guess it is possible.

David

Re: Can the automatic daily update commits be stopped?

[Will Newton]

On 6 January 2015 at 15:54, David Howells <dhowells@redhat.com> wrote:
> H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> Try this in binutils-gdb tree:
>>
>> #  echo "$(git remote -v | grep fetch | awk '{ print $2}') on $(git
>> name-rev --name-only HEAD) commit $(git log -1 --pretty=%H)"
>
> I suspect that what Andreas is getting at is that you can't compare SHA1 sums
> to gain any information on the relative age of two commits.

I guess the situation is you have no access to git (and is unlikely as
you probably have a clone somewhere as a developer) and you have two
tarballs and wish to determine which is more recent? You can resort to
reading changelogs at that point. Is there an actual situation where
this information is actually needed?

It seems a bit like the argument of monotonic version numbers versus
SHA hashes in the early days of DVCS and it turns out we didn't really
need monotonic version numbers, we were just used to having them.

-- 
Will Newton
Toolchain Working Group, Linaro

Re: Can the automatic daily update commits be stopped?

[H.J. Lu]

On Tue, Jan 6, 2015 at 8:14 AM, David Howells <dhowells@redhat.com> wrote:
> H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> Can you tell me what other info you need:
>>
>> [hjl@gnu-6 binutils-gdb]$ echo "$(git remote -v | grep fetch | awk '{
>> print $2}') on $(git name-rev --name-only HEAD) commit $(git log -1
>> --pretty=%H)"
>> ssh://hjl@sourceware.org/git/binutils-gdb.git on master commit
>> 533d0af0b8a8127b6f189222fc57aa11ce7aab2c
>
> I would guess Andreas would probably want date at least - but there's still
> the problem of multiple commits within a day.  Even within a single second, I
> would guess it is possible.
>
> David

I created users/hjl/version branch.  I got:

[hjl@gnu-6 build-x86_64-linux]$ ./ld/ld-new --version
GNU ld (GNU Binutils) 2.25.51.20150106
 from git://sourceware.org/git/binutils.git commit
85880250e591a51624d24db653aaace0c5ce5943 on users/hjl/version
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

It is independent of BFD_VERSION_DATE in bfd/version.h.


-- 
H.J.

Can the automatic daily update commits be stopped, take 2

[David Howells]

David Howells <dhowells@redhat.com> wrote:

> Can the automatic "daily update" and "Automatic date update in version.in"
> commits be stopped?  Or at least only performed if the last commit was not
> itself such a commit?

I note that these are still being produced.  Is it possible to stop them as
they make a mess of the git history?

I think Andreas Schwab suggested that it might be necessary as you can't
directly compare two git hashes without a repo handy to give them context -
but how often is that actually a problem?  If you are comparing two points on
the same branch, you can consult the ChangeLog files and if they're produced
separate branches, then comparing the dates is potentially meaningless anyway.

Further, not having an incrementing version doesn't necessarily mean that you
can't name published tarballs for the date on which they're produced.

David

Re: Can the automatic daily update commits be stopped, take 2

[H.J. Lu]

On Thu, Jan 28, 2016 at 2:56 PM, David Howells <dhowells@redhat.com> wrote:
> David Howells <dhowells@redhat.com> wrote:
>
>> Can the automatic "daily update" and "Automatic date update in version.in"
>> commits be stopped?  Or at least only performed if the last commit was not
>> itself such a commit?
>
> I note that these are still being produced.  Is it possible to stop them as
> they make a mess of the git history?
>
> I think Andreas Schwab suggested that it might be necessary as you can't
> directly compare two git hashes without a repo handy to give them context -
> but how often is that actually a problem?  If you are comparing two points on
> the same branch, you can consult the ChangeLog files and if they're produced
> separate branches, then comparing the dates is potentially meaningless anyway.
>
> Further, not having an incrementing version doesn't necessarily mean that you
> can't name published tarballs for the date on which they're produced.
>
> David

I don't mind stopping updating bfd/version.h as long as "ld --version"
displays different versions from linkers of different dates.

-- 
H.J.

Re: Can the automatic daily update commits be stopped, take 2

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

On 28 Jan 2016 15:01, H.J. Lu wrote:
> On Thu, Jan 28, 2016 at 2:56 PM, David Howells <dhowells@redhat.com> wrote:
> > David Howells <dhowells@redhat.com> wrote:
> >> Can the automatic "daily update" and "Automatic date update in version.in"
> >> commits be stopped?  Or at least only performed if the last commit was not
> >> itself such a commit?
> >
> > I note that these are still being produced.  Is it possible to stop them as
> > they make a mess of the git history?
> >
> > I think Andreas Schwab suggested that it might be necessary as you can't
> > directly compare two git hashes without a repo handy to give them context -
> > but how often is that actually a problem?  If you are comparing two points on
> > the same branch, you can consult the ChangeLog files and if they're produced
> > separate branches, then comparing the dates is potentially meaningless anyway.
> >
> > Further, not having an incrementing version doesn't necessarily mean that you
> > can't name published tarballs for the date on which they're produced.
> 
> I don't mind stopping updating bfd/version.h as long as "ld --version"
> displays different versions from linkers of different dates.

s/dates/source trees (e.g. diff git sha1)/
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Can the automatic daily update commits be stopped, take 2

[H.J. Lu]

On Thu, Jan 28, 2016 at 3:15 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 28 Jan 2016 15:01, H.J. Lu wrote:
>> On Thu, Jan 28, 2016 at 2:56 PM, David Howells <dhowells@redhat.com> wrote:
>> > David Howells <dhowells@redhat.com> wrote:
>> >> Can the automatic "daily update" and "Automatic date update in version.in"
>> >> commits be stopped?  Or at least only performed if the last commit was not
>> >> itself such a commit?
>> >
>> > I note that these are still being produced.  Is it possible to stop them as
>> > they make a mess of the git history?
>> >
>> > I think Andreas Schwab suggested that it might be necessary as you can't
>> > directly compare two git hashes without a repo handy to give them context -
>> > but how often is that actually a problem?  If you are comparing two points on
>> > the same branch, you can consult the ChangeLog files and if they're produced
>> > separate branches, then comparing the dates is potentially meaningless anyway.
>> >
>> > Further, not having an incrementing version doesn't necessarily mean that you
>> > can't name published tarballs for the date on which they're produced.
>>
>> I don't mind stopping updating bfd/version.h as long as "ld --version"
>> displays different versions from linkers of different dates.
>
> s/dates/source trees (e.g. diff git sha1)/
> -mike

It is hard to tell which one is newer without using git source.


-- 
H.J.

Re: Can the automatic daily update commits be stopped, take 2

[Matt Rice]

On Thu, Jan 28, 2016 at 4:25 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jan 28, 2016 at 3:15 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On 28 Jan 2016 15:01, H.J. Lu wrote:
>>> On Thu, Jan 28, 2016 at 2:56 PM, David Howells <dhowells@redhat.com> wrote:
>>> > David Howells <dhowells@redhat.com> wrote:
>>> >> Can the automatic "daily update" and "Automatic date update in version.in"
>>> >> commits be stopped?  Or at least only performed if the last commit was not
>>> >> itself such a commit?
>>> >
>>> > I note that these are still being produced.  Is it possible to stop them as
>>> > they make a mess of the git history?
>>> >
>>> > I think Andreas Schwab suggested that it might be necessary as you can't
>>> > directly compare two git hashes without a repo handy to give them context -
>>> > but how often is that actually a problem?  If you are comparing two points on
>>> > the same branch, you can consult the ChangeLog files and if they're produced
>>> > separate branches, then comparing the dates is potentially meaningless anyway.
>>> >
>>> > Further, not having an incrementing version doesn't necessarily mean that you
>>> > can't name published tarballs for the date on which they're produced.
>>>
>>> I don't mind stopping updating bfd/version.h as long as "ld --version"
>>> displays different versions from linkers of different dates.
>>
>> s/dates/source trees (e.g. diff git sha1)/
>> -mike
>
> It is hard to tell which one is newer without using git source.

I always thought it would be nice to try and achieve this through
using git smudge/clean filters in gitattributes but never quite got to
it

Re: Can the automatic daily update commits be stopped, take 2

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]

On 28 Jan 2016 16:25, H.J. Lu wrote:
> On Thu, Jan 28, 2016 at 3:15 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On 28 Jan 2016 15:01, H.J. Lu wrote:
> >> On Thu, Jan 28, 2016 at 2:56 PM, David Howells <dhowells@redhat.com> wrote:
> >> > David Howells <dhowells@redhat.com> wrote:
> >> >> Can the automatic "daily update" and "Automatic date update in version.in"
> >> >> commits be stopped?  Or at least only performed if the last commit was not
> >> >> itself such a commit?
> >> >
> >> > I note that these are still being produced.  Is it possible to stop them as
> >> > they make a mess of the git history?
> >> >
> >> > I think Andreas Schwab suggested that it might be necessary as you can't
> >> > directly compare two git hashes without a repo handy to give them context -
> >> > but how often is that actually a problem?  If you are comparing two points on
> >> > the same branch, you can consult the ChangeLog files and if they're produced
> >> > separate branches, then comparing the dates is potentially meaningless anyway.
> >> >
> >> > Further, not having an incrementing version doesn't necessarily mean that you
> >> > can't name published tarballs for the date on which they're produced.
> >>
> >> I don't mind stopping updating bfd/version.h as long as "ld --version"
> >> displays different versions from linkers of different dates.
> >
> > s/dates/source trees (e.g. diff git sha1)/
> 
> It is hard to tell which one is newer without using git source.

that isn't what you said.  your statement says that, even if you use the
same source, but built on different date, you get diff output.  i'm saying
that, like David, the daily bumps shouldn't happen unless an actual change
landed.  so if nothing was committed between Jan 10th and Jan 20th, my
builds from Jan 15th should be the same as Jan 10th.

if your only requirement is that `ld --version` accurately reflect the git
version, and include a timestamp for that git commit so you can easily do a
compare w/out sources, then that doesn't even need a daily bump to happen.

i would point out that even today your requirements aren't met -- the bump
is a daily one which means the ld built at 00:01 can be radically different
from the one built at 23:59, yet they still report the same --version.

in the CVS world, doing a daily bump was needed because the VCS itself had
no way of providing a fingerprint.  git has no such limitation, so doing a
bump at all is anachronistic.
$ git log -1 --format='format:%ci %H' HEAD
2016-01-24 19:24:18 -0500 1fe8799f24883105c476677803dfb5acc0b2ca63
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Can the automatic daily update commits be stopped, take 2

[Andreas Schwab]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> It is hard to tell which one is newer without using git source.

git describe would be the right tool if only we had proper annotated
release tags.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can the automatic daily update commits be stopped, take 2

[Joel Brobecker]

> > It is hard to tell which one is newer without using git source.
> 
> git describe would be the right tool if only we had proper annotated
> release tags.

Which release tags do you have in mind, and what do we need to do
to fix them?

-- 
Joel

Re: Can the automatic daily update commits be stopped, take 2

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

>> > It is hard to tell which one is newer without using git source.
>> 
>> git describe would be the right tool if only we had proper annotated
>> release tags.
>
> Which release tags do you have in mind, and what do we need to do
> to fix them?

Just make them annotated instead of lightweight (see git-tag(1)).  Even
better if they are signed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can the automatic daily update commits be stopped, take 2

[Joel Brobecker]

> > Which release tags do you have in mind, and what do we need to do
> > to fix them?
> 
> Just make them annotated instead of lightweight (see git-tag(1)).  Even
> better if they are signed.

GDB release tags have been both annotated and signed ever since
someone (was it you?) asked me about it.

AFAICT, Binutils release tags are also annotated (but not signed).

You'll need to be more precise about what's still not working
for you. In particular, I don't think the signing makes any difference
to git-describe.

-- 
Joel

Re: Can the automatic daily update commits be stopped, take 2

[H.J. Lu]

On Fri, Jan 29, 2016 at 5:37 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > Which release tags do you have in mind, and what do we need to do
>> > to fix them?
>>
>> Just make them annotated instead of lightweight (see git-tag(1)).  Even
>> better if they are signed.
>
> GDB release tags have been both annotated and signed ever since
> someone (was it you?) asked me about it.
>
> AFAICT, Binutils release tags are also annotated (but not signed).
>
> You'll need to be more precise about what's still not working
> for you. In particular, I don't think the signing makes any difference
> to git-describe.

My concerns are

1. Someone downloads a tar ball and builds it.   "ld --version" should
be able to
tell at least the date when the tar ball was made.
2. Someone checks out a branch,  makes some changes, checks into his/her
branch and builds it,  "ld --version" should be able to tell the date
when the branch
was taken.

-- 
H.J.

Re: Can the automatic daily update commits be stopped, take 2

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> GDB release tags have been both annotated and signed ever since
> someone (was it you?) asked me about it.
>
> AFAICT, Binutils release tags are also annotated (but not signed).

Yes, you are right, sorry.

> You'll need to be more precise about what's still not working
> for you. In particular, I don't think the signing makes any difference
> to git-describe.

The problem is actually that there are no useful tags on master, so git
describe doesn't give something useful there.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can the automatic daily update commits be stopped, take 2

[Joel Brobecker]

> 1. Someone downloads a tar ball and builds it.   "ld --version" should
> be able to
> tell at least the date when the tar ball was made.

A date is what we have at the moment, but is far to imprecise, IMO.

> 2. Someone checks out a branch,  makes some changes, checks into his/her
> branch and builds it,  "ld --version" should be able to tell the date
> when the branch was taken.

When the branch was taken? If it were a short-lived branch, why not,
but what about a longer-term branch?

Here is a counter proposal: Modify the build procedures so as to
first check whether the sources are part of a git repository.
If yes, then produce a meaning version info from there. If not,
then provide a way to provide the meaningful info through another
method. For instance, the nightly source packaging could drop
a specific file with the needed information. We could even make
the build first generate the version info in the file when we
have a git repo, and then do the build using the version info
from that file.

-- 
Joel

Re: Can the automatic daily update commits be stopped, take 2

[H.J. Lu]

On Fri, Jan 29, 2016 at 6:01 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> 1. Someone downloads a tar ball and builds it.   "ld --version" should
>> be able to
>> tell at least the date when the tar ball was made.
>
> A date is what we have at the moment, but is far to imprecise, IMO.

The more precise, the better.

>> 2. Someone checks out a branch,  makes some changes, checks into his/her
>> branch and builds it,  "ld --version" should be able to tell the date
>> when the branch was taken.
>
> When the branch was taken? If it were a short-lived branch, why not,
> but what about a longer-term branch?

You can tell the long-term branch, which the short-lived branch is based on,
and the date from the version string even if the branch is short-lived.

> Here is a counter proposal: Modify the build procedures so as to
> first check whether the sources are part of a git repository.
> If yes, then produce a meaning version info from there. If not,
> then provide a way to provide the meaningful info through another
> method. For instance, the nightly source packaging could drop
> a specific file with the needed information. We could even make
> the build first generate the version info in the file when we
> have a git repo, and then do the build using the version info
> from that file.

The more meaningful source info, the better.


-- 
H.J.

Re: Can the automatic daily update commits be stopped, take 2

[David Howells]

H.J. Lu <hjl.tools@gmail.com> wrote:

> I don't mind stopping updating bfd/version.h as long as "ld --version"
> displays different versions from linkers of different dates.

Can you at least reduce the daily bumps to only happen if there has been at
least one change since the last daily bump?  Ie. if the head commit on any
branch is not itself a daily bump.

David