[PATCH] Added code to output the age as seconds instead of "0 min."

Luke SanAntonio lsworkemail112 at gmail.com
Sat Sep 29 21:16:55 CEST 2012


"reflect the actual data up-to-date" should be: "reflect the actual,
up-to-date data..."

Sorry about that...

On Sat, Sep 29, 2012 at 3:14 PM, Luke SanAntonio
<lsworkemail112 at gmail.com> wrote:
> Okay, I understand now.
> I guess my take on the matter is a user who selects caching already has accepted
> that the data generated might not correctly reflect the actual data
> up-to-date... these users
> know it going in, so I don't think it's a huge concern...
>
> Sorry about my previous misunderstanding...
>  - Luke
>
> On Sat, Sep 29, 2012 at 2:51 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> On Sat, Sep 29, 2012 at 8:43 PM, Luke SanAntonio
>> <lsworkemail112 at gmail.com> wrote:
>>> Hi Jason,
>>>
>>>     First of all, good call with the cache, it hadn't even crossed my mind...
>>> Second I think the cache isn't something we need to worry about...
>>> mostly because
>>> cgit is very lightweight, and I think for now, we don't have to be too
>>> worried about
>>> performance, correct me if I'm wrong though... Also it seems to me
>>> that with or without the cache,
>>> every cgit page I've ever come across seems to load in much less time
>>> than a second...
>>
>>
>> Hey, sorry, just to be clear -- my concern isn't about performance,
>> but about this:
>>
>> If you set the cgit cache to 1 minute, and the granularity of
>> timestamps is only 1 minute, then for the most part, the pages, though
>> cached, will see up to date.
>>
>> However if you set the cgit cache to 1 minute, and the granularity of
>> the timestamps is 1 second, then for the most part, the pages will
>> seem out of date.
>>
>> But this is just how caching is, so I'm not sure it's such a big
>> concern. Just throwing it out there, in case anyone had some elegant
>> solution or attitude about it.




More information about the CGit mailing list