From: Jakub Narebski <jnareb@gmail.com>
To: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCHv2 5/6] gitweb: last-modified time should be commiter, not author
Date: Fri, 6 Feb 2009 22:12:05 +0100 [thread overview]
Message-ID: <200902062212.08857.jnareb@gmail.com> (raw)
In-Reply-To: <cb7bb73a0902060314u4741528bs196a43d45ff7f283@mail.gmail.com>
On Fri, 06 Feb 2009, Giuseppe Bilotta wrote:
> On Thu, Feb 5, 2009 at 12:38 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
>>
>>> The last-modified time header added by RSS to increase cache hits from
>>> readers should be set to the date the repository was last modified. The
>>> author time in this respect is not a good guess because the last commit
>>> might come from a oldish patch.
>>>
>>> Use the committer time for the last-modified header to ensure a more
>>> correct guess of the last time the repository was modified.
[...]
>> Second, author time reflects when change (commit) was made, according
>> to authors (perhaps skewed) clock. Committer time reflects when given
>> commit (version of a commit) was entered into repository, or to be more
>> exact into some clone of given project. But there is also an issue of
>> when changes got into given instance of repository (given clone): that
>> I guess might be found by stat-ing HEAD (if it arrived by commit),
>> FETCH_HEAD (if it arrived by fetch or pull) and ??? (if it arrived by
>> push)... err... it looks like it wouldn't work in most common case,
>> sorry, unless we want to stat all refs and packed-refs file. But while
>> this date might be better for Last-Modified, I'm not sure if it is good
>> at all for publication date.
>>
>> So committer time is better than author time, and looks like good
>> middle ground.
>
> Oops should have finished reading your comments before my previous
> reply. The solution would be to introduce a way to determine robustly
> when a branch was last _physically_ updated. Checking the
> corresponding entry in refs/ would work for non-packed refs, and maybe
> one would hope that if the ref got packed, it means it hasn't updated
> in a long time ... but I'm not enough of an expert on git's internal
> to really know about this. Suggestions?
The point is I am not that sure if the date branch was _physically_
updated (it was updated in given clone of repository) is a good
choice for publish date in feed (RSS or Atom), whether it is good
choice for Last-Modified (and If-Modified-Since), and whether publish
date can be different from Last-Modified.
Using committime doesn't ensure that it is monotonical (but it is
highly probable, much more than authortime), but it is the same for
every clone of repository, and for every gitweb installation that
hosts given repository.
Using update time does ensure that it is monotonical, and it
wouldn't ever be earlier than the time repository started to be
available, but it changes from clone to clone.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2009-02-06 21:13 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 11:50 [PATCHv2 0/6] gitweb: feed metadata enhancements Giuseppe Bilotta
2009-01-26 11:50 ` [PATCHv2 1/6] gitweb: channel image in rss feed Giuseppe Bilotta
2009-01-26 11:50 ` [PATCHv2 2/6] gitweb: feed generator metadata Giuseppe Bilotta
2009-01-26 11:50 ` [PATCHv2 3/6] gitweb: rss feed managingEditor Giuseppe Bilotta
2009-01-26 11:50 ` [PATCHv2 4/6] gitweb: rss channel date Giuseppe Bilotta
2009-01-26 11:50 ` [PATCHv2 5/6] gitweb: last-modified time should be commiter, not author Giuseppe Bilotta
2009-01-26 11:50 ` [PATCHv2 6/6] gitweb: check if-modified-since for feeds Giuseppe Bilotta
2009-02-05 2:03 ` Jakub Narebski
2009-02-06 11:19 ` Giuseppe Bilotta
2009-02-04 23:38 ` [PATCHv2 5/6] gitweb: last-modified time should be commiter, not author Jakub Narebski
2009-02-06 11:14 ` Giuseppe Bilotta
2009-02-06 21:12 ` Jakub Narebski [this message]
2009-02-06 23:00 ` Giuseppe Bilotta
2009-02-11 3:10 ` Deskin Miller
2009-02-11 9:02 ` Giuseppe Bilotta
2009-02-11 9:18 ` Jakub Narebski
2009-02-11 9:54 ` Giuseppe Bilotta
2009-02-12 4:50 ` Deskin Miller
2009-02-12 9:07 ` Jakub Narebski
2009-02-12 9:52 ` Giuseppe Bilotta
2009-02-12 10:11 ` Jakub Narebski
2009-02-12 11:23 ` Giuseppe Bilotta
2009-02-04 23:24 ` [PATCHv2 4/6] gitweb: rss channel date Jakub Narebski
2009-02-06 11:10 ` Giuseppe Bilotta
2009-02-04 23:19 ` [PATCHv2 3/6] gitweb: rss feed managingEditor Jakub Narebski
2009-02-06 11:03 ` Giuseppe Bilotta
2009-02-04 23:15 ` [PATCHv2 2/6] gitweb: feed generator metadata Jakub Narebski
2009-02-06 11:01 ` Giuseppe Bilotta
2009-02-06 11:21 ` Jakub Narebski
2009-02-04 22:56 ` [PATCHv2 1/6] gitweb: channel image in rss feed Jakub Narebski
2009-02-06 10:55 ` Giuseppe Bilotta
2009-01-28 20:58 ` [PATCHv2 0/6] gitweb: feed metadata enhancements Junio C Hamano
2009-01-28 21:48 ` Jakub Narebski
2009-01-28 21:57 ` Giuseppe Bilotta
2009-01-28 22:03 ` Junio C Hamano
2009-02-06 22:42 ` Jakub Narebski
2009-02-07 0:24 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200902062212.08857.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=giuseppe.bilotta@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).