On Thu, Feb 5, 2009 at 12:38 AM, Jakub Narebski <jnareb@xxxxxxxxx> 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
