Re: RCS keyword expansion

From: Zakirov Salikh <salikh@gmail.com>
Date: Oct 12, 2007, 23:52 UTC
Message-ID: <eb5812d90710121652g24b1177ao685c1ce4e0626c2d@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0710122341160.25221@racer.site>

On 13/10/2007, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 7 quoted lines

> > * 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.
>
> No.
> When changing branches, this is not the commit you think it is.

Exactly. When switching branches, or merging or fast-forwarding several commits, the last commit may not be correct. The last commit is only correct for the files being updated by the fast-forward to exactly one commit. Which seem to be pretty natural for the use case of checkout-only web-published workspace.

> But maybe you humour me and tell me in which context such a smudge filter
> is of use.  I have yet to encounter an argument that convinces me.

Your comment prompted me to think about a narrower case of fast-forwaring to one revision. In that case, 'smudge' script can have commit identifier in FETCH_HEAD, so the example script from previous message with a little modification:

    $rev = `git-rev-parse FETCH_HEAD`

gives *exact* solution to the originally stated problem, though for the specific case when the web server directory is a checkout-only working directory, which pulls changes automatically from master server (as opposed to, e.g., pushing changes to web server). Even if the server pulls several revisions at once, it is likely that they are done in a close succession (otherwise automated update would have picked them separately), and important part in web page timestamp is usually date.

Too bad I do not really have a web server and do not need to maintain timestamps in web pages ... :) git scriptability always amazed me.