Re: [PATCHv2 5/6] gitweb: last-modified time should be commiter, not author
- From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date
- Feb 6, 2009, 11:14 UTC
- Message-ID
- <cb7bb73a0902060314u4741528bs196a43d45ff7f283@mail.gmail.com>
- In-Reply-To
- <200902050038.57999.jnareb@gmail.com>
On Thu, Feb 5, 2009 at 12:38 AM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 30 quoted lines
> 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. > > First, changing %latest_date from author time to committer time affects > not only Last-Modified HTTP header, but (after this series) also > various "publication dates" in the feed contents. But I think that for > all those committer time is better approximation of publication date > and last change date than author time. > > 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?
-- Giuseppe "Oblomov" Bilotta