Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov <ptr@void-ptr.info>]

On Thu, 21 Sep 2017 01:42:28 -0700
Matt Rice <ratmice@gmail.com> wrote:

> On Wed, Sep 20, 2017 at 9:58 PM, Fiodar Stryzhniou via gdb
> <gdb@sourceware.org> 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
> filter,
>               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
> https://www.agwa.name/projects/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.