Re: [PATCH] gitweb: last-modified time should be commiter, not author

On Mon, Jan 26, 2009 at 2:54 AM, Jakub Narebski [off-list ref] wrote:

On Sun, 25 Jan 2009, Giuseppe Bilotta wrote:

quoted

Subject: [PATCH] gitweb: last-modified time should be commiter, not author

Should be really either "[PATCH 1/2]" or "[PATCH 5/4]" or "[PATCH 5/6]"
just in case for the next patch, because next patch _depends_ on this
one, and just in case of threading problem it should be marked as it;
it also makes easier to apply patches from emails saved as individual
files each.

I'll resend the whole 6-patch series cc'ing Junio too

quoted

Use the committer time for the last-modified header to ensure a more
correct guess of the last time the repository was modified.

Good catch, good thinking IMHO. Committer date has much better chance
to be monotonic than author date, and is more close related to
_publishing_ date (author date is more of _creation_ date).

BTW, it is still not good enough. Consider a remote repo to which you
just pushed some changes you commited last week. The last-modified
date would be last-week, even if you just pushed those changes.

This used to be a problem for us on ruby-rbot because even when
watching the feed we would get no updates on the irc channel (the bot
thought the feed could still be cached). the if-modified thing seems
to have fixed this though.

Lack signoff; if Junio forges it (or you reply that it should be
signed off), you can add from me

Acked-by: Jakub Narebski <redacted>


P.S. I wonder what other web interfaces do, for example cgit. I guess
that web interfaces for other SCMs like SVN::Web, ViewVC etc. do not
have this problem because they have only one, single date.

HEAD'ing a cgit atom url gives a last-modified date one hour from the
request, it seems. This is actually a typical (and not nice) behaviour
of many CGI scripts.

-- 
Giuseppe "Oblomov" Bilotta