This is the mail archive of the
mailing list for the binutils project.
Re: meaning of "Automatic date update in version.in" commits
- From: Petr Ovtchenkov <ptr at void-ptr dot info>
- To: Matt Rice <ratmice at gmail dot com>
- Cc: Fiodar Stryzhniou <fedor_qd at mail dot ru>, Andreas Schwab <schwab at linux-m68k dot org>, Binutils <binutils at sourceware dot org>, Joel Brobecker <brobecker at adacore dot com>, Matthias Klose <doko at ubuntu dot com>, GDB <gdb at sourceware dot org>
- Date: Thu, 21 Sep 2017 13:58:45 +0300
- Subject: Re: meaning of "Automatic date update in version.in" commits
- Authentication-results: sourceware.org; auth=none
- References: <yyRSFRMK2lz0.xJ9T1cbZ@smtp.mail.ru> <CACTLOFoyTeU+CG9vo8Xf+tWmr7869c_NMrRNUo4X90Ov9S2DyQ@mail.gmail.com>
On Thu, 21 Sep 2017 01:42:28 -0700
Matt Rice <firstname.lastname@example.org> wrote:
> On Wed, Sep 20, 2017 at 9:58 PM, Fiodar Stryzhniou via gdb
> <email@example.com> wrote:
> > I propose set date with git hook. With every commit create bfd/version.in before commit and
> > vice versa.
> Hmm, I don't know much about git hooks per se, but I didn't think e.g.
> server side hooks could filter on commit?
> Anyhow, I see 2 options, assuming there are some list of requirements
> for when git is required:
> compile time? no
> configure time? (C.)
> autoreconf time? n/a
> checkout time? always (A.)
> commit time? always (B.)
Date is worst thing that you may use in SONAME. Especially in conjunction
with attempts to use DVCS as date source. (D == _Distributed_, so _no
time ordering_). And I should repeat:
- from datestamps equality not follow ABI compatibility,
- from datestamps inequality not follow ABI incompatibility.
What you want achieve with SONAME variations?
> option A. seems to be using git smudge/filter to on checkout populate
> the version.in using a smudge rule, and then filtering it out using a
> acting much like the RCS keywords...
> pros: no extra commit stuff at all
> cons: requires setting up git config stuff in the repository for
> executing the smudge/filter rules on checkout
> this should likely be checked by the configure process e.g.
> configure should produce an error telling the user to enable the
> smudge/filter rules
> when the version is $Date$ rather an actual date...
> option B. would be somewhat the reverse of this, using a git filter,
> to modify the commit to insert a date into commits,
> it would require that committers (rather than people
> checking out) modify their git config to update version.in on commit.
> would act somewhat like the project git-crypt
> perhaps this is what Fiodar is referring to above?
> we would then probably require Brobecke's git hooks, to
> check that the commit/filter was run before commit
> Option A. shifts the burden onto users to checkout the repository with
> the filters enabled
> Option B. causes some developer discomfort when it comes to merging
> and branches and what not, and it would probably show up in every
> patch review.
> Option C. requiring git at configure time, could be inconvenient for
> some downstream distros with build machinery that doesn't include git.
> I personally would not consider it an option...
> out of these 3, my preference would be A,
> this is quite counter to the preference I would typically have, e.g.
> jump through that extra hoop so it doesn't get shifted to the user
> compiling the software.
> but I think that the B. hoop is perhaps on fire, and would end up more
> annoying than the cron commit we have now...
> So in that regard the choice largely falls to: is the existing cron
> mechanism annoying enough that we would burden the user with A?
> I think that since it is a one-time thing when cloning a
> repository/setting up the repository it is at least worth considering
> since leaving it as it is does add overhead for e.g. the build bot
> finding commit broke, and git bisect.