Re: RCS keyword expansion

[Salikh Zakirov <salikh@gmail.com>]

Peter Karlsson wrote:
> But that's not what I want. Then my build procedure would need to do a
> "git status", or whatever you use to get the last commit information
> about a file, on each file that is changed and is to be installed. It
> would be a lot easier if that was done already on checkout through some
> kind of hook.

For what it's worth, I've made a small exercise on git scripting 
(which I'm total newbie in), and tried to use filter mechanism
(smudge/clean) for solving the problem Peter stated.

Fundamental problems of this approach were discussed in full
on the mailing list, however, as I understand Peter's situation,
they do not apply, as the web site workspace is 'checkout-only',
and no actual work (commits) are made there. 
Thus, it will not cause any merge problems etc.

Anyway, smudge/clean does not give the immediate solution to the problem
because of smaller technical shortcomings:
* smudge filter is not passed a name of file being checked out, 
  so it is not possible to exactly find the commit identifier.
  However, this is alleviated by the fact that 'smudge' is only being run
  for the changed files, so the last commit *is* the needed one.

* smudge filter is not passed a commit identifier. This is a bit more serious,
  as this information is nowhere to get from otherwise. I tried to use 'HEAD'
  value, but apparently it is not yet updated at the moment 'smudge' is being
  run, so the files end up with the date of the "previous" commit rather than
  the commit being checked out. "Previous" means the commit that was checked
  out before. The problem gets worse if different branch is checkout out,
  as the files get the timestamp of a previous branch.

AFAIR, lack of information in smudge filter was intentional, to discourage
this particular use of smudge/clean mechanism. However, I think this can be
reconsidered given the Peter's use case: "checkout-only" workspace for immediate
publishing to webserver. Alternatively, anyone interested in this use case
could implement additional smudge arguments as a site-local patch.

And then, there are small annoyances, which seems to be inevitable:
* if you change 'clean' filter and check out earlier revision, it will be
  reported as having modifications (due to changed 'clean' definition).

Below is what I ended up with:

.gitattributes:
* filter=date

.git/config:
[filter "date"]
        smudge = .git/smudge
        clean = .git/clean

.git/clean:
#!/usr/bin/perl -p
s#\$Date[^\$]*\$#\$Date\$#;

.git/smudge:
#!/usr/bin/perl

use POSIX qw(strftime);
$branch = `git-symbolic-ref HEAD`; chomp($branch);
$rev = `git-rev-list -n 1 $branch`; chomp($rev);
open REV, "git show --pretty=raw $rev|";
$time = time; # default to current time
while (<REV>) {
    if (/^committer.* (\d+) [\-+]\d*$/) {
        $time = $1;
    }
}
close REV;

$date = strftime "%Y-%m-%d %H:%M:%S", localtime($time);
while (<>) {
    s#\$Date[^\$]*\$#\$Date: $date\$#;
    print;
}