On 13/10/2007, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
quoted text
> > * 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.

quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html