This is the mail archive of the
mailing list for the binutils project.
Re: Can the automatic daily update commits be stopped, take 2
- From: Matt Rice <ratmice at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: David Howells <dhowells at redhat dot com>, Binutils <binutils at sourceware dot org>, Nick Clifton <nickc at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Thu, 28 Jan 2016 16:31:04 -0800
- Subject: Re: Can the automatic daily update commits be stopped, take 2
- Authentication-results: sourceware.org; auth=none
- References: <20428 dot 1420542531 at warthog dot procyon dot org dot uk> <25281 dot 1454021771 at warthog dot procyon dot org dot uk> <CAMe9rOoZ7PL28NfHoR4azfwQgixg+7y7ykcOg24pvBEiLc6kuA at mail dot gmail dot com> <20160128231538 dot GF14840 at vapier dot lan> <CAMe9rOqNC4F7VuCMRMsjWEmafnbU82tmvd1ehc7pLnRzLbBshg at mail dot gmail dot com>
On Thu, Jan 28, 2016 at 4:25 PM, H.J. Lu <email@example.com> wrote:
> On Thu, Jan 28, 2016 at 3:15 PM, Mike Frysinger <firstname.lastname@example.org> wrote:
>> On 28 Jan 2016 15:01, H.J. Lu wrote:
>>> On Thu, Jan 28, 2016 at 2:56 PM, David Howells <email@example.com> wrote:
>>> > David Howells <firstname.lastname@example.org> 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.
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