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

[Giuseppe Bilotta <giuseppe.bilotta@gmail.com>]

On Mon, Jan 26, 2009 at 2:54 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 25 Jan 2009, Giuseppe Bilotta wrote:
>
>> 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

>> 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 <jnareb@gmail.com>
>
>
> 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