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

On Wed, Sep 20, 2017 at 9:58 PM, Fiodar Stryzhniou via gdb
<[email protected]> 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.)

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.