* [PATCH] Added code to output the age as seconds instead of "0 min."
@ 2012-08-18 20:37 lsworkemail112
0 siblings, 0 replies; 20+ messages in thread
From: lsworkemail112 @ 2012-08-18 20:37 UTC (permalink / raw)
---
ui-shared.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/ui-shared.c b/ui-shared.c
index 43166af..a1f9d70 100644
--- a/ui-shared.c
+++ b/ui-shared.c
@@ -594,6 +594,11 @@ void cgit_print_age(time_t t, time_t max_relative, const char *format)
return;
}
+ if (secs < TM_MIN) {
+ htmlf("<span class='age-mins'>%.0f sec.</span>",
+ secs * 1.0);
+ return;
+ }
if (secs < TM_HOUR * 2) {
htmlf("<span class='age-mins'>%.0f min.</span>",
secs * 1.0 / TM_MIN);
--
1.7.12-rc0
^ permalink raw reply [flat|nested] 20+ messages in thread
* Maintaining My Own Cgit Tree
@ 2012-09-27 1:39 Jason
2012-09-29 0:30 ` [PATCH] Added code to output the age as seconds instead of "0 min." lsworkemail112
0 siblings, 1 reply; 20+ messages in thread
From: Jason @ 2012-09-27 1:39 UTC (permalink / raw)
Hi everyone,
I haven't heard from Lars for almost 7 months now. I've contributed
chunks of code to cgit in the past, and I continue to improve it now,
but with no one to send patches to, I've just been maintaining my own
tree, with features such as better support for the latest gitolite,
among other fixes.
Until Lars appears on the scene again, I'm happy to aggregate a
patches from everyone in my tree, and then when he reemerges from
wherever he is, he'll have a nice unified place to start merging what
we've been up to during his absence.
If others like this plan, by all means resend to this thread the
patches and enhancements you've been working on.
You can see what I've added myself at: http://git.zx2c4.com/cgit
Thanks,
Jason Donenfeld
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-27 1:39 Maintaining My Own Cgit Tree Jason
@ 2012-09-29 0:30 ` lsworkemail112
2012-09-29 5:20 ` Jason
0 siblings, 1 reply; 20+ messages in thread
From: lsworkemail112 @ 2012-09-29 0:30 UTC (permalink / raw)
Before this patch, the program will output the age as "0 min."
Which isn't as specific as it can be... Although this patch
doesn't do any fancy automatic crap like use javascript to update
the value realtime, it still adds a much needed feature...
---
ui-shared.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/ui-shared.c b/ui-shared.c
index 43166af..a1f9d70 100644
--- a/ui-shared.c
+++ b/ui-shared.c
@@ -594,6 +594,11 @@ void cgit_print_age(time_t t, time_t max_relative, const char *format)
return;
}
+ if (secs < TM_MIN) {
+ htmlf("<span class='age-mins'>%.0f sec.</span>",
+ secs * 1.0);
+ return;
+ }
if (secs < TM_HOUR * 2) {
htmlf("<span class='age-mins'>%.0f min.</span>",
secs * 1.0 / TM_MIN);
--
1.7.12-rc0
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 0:30 ` [PATCH] Added code to output the age as seconds instead of "0 min." lsworkemail112
@ 2012-09-29 5:20 ` Jason
2012-09-29 18:43 ` lsworkemail112
0 siblings, 1 reply; 20+ messages in thread
From: Jason @ 2012-09-29 5:20 UTC (permalink / raw)
Hey Luke,
Looks great, merged.
My one concern, however, which might make me reconsider merging this
patch is -- what about the cache? Adding explicit seconds makes any
caching appear even more out of date than just minutes. But maybe this
isn't a big deal. What do you think?
Jason
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 5:20 ` Jason
@ 2012-09-29 18:43 ` lsworkemail112
2012-09-29 18:51 ` Jason
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: lsworkemail112 @ 2012-09-29 18:43 UTC (permalink / raw)
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...
Thanks for considering my patch =D
- Luke
On Sat, Sep 29, 2012 at 1:20 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hey Luke,
>
> Looks great, merged.
>
> My one concern, however, which might make me reconsider merging this
> patch is -- what about the cache? Adding explicit seconds makes any
> caching appear even more out of date than just minutes. But maybe this
> isn't a big deal. What do you think?
>
> Jason
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 18:43 ` lsworkemail112
@ 2012-09-29 18:51 ` Jason
2012-09-29 19:14 ` lsworkemail112
2012-09-30 5:51 ` mailings
2012-10-01 13:56 ` webmaster
2 siblings, 1 reply; 20+ messages in thread
From: Jason @ 2012-09-29 18:51 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 18:51 ` Jason
@ 2012-09-29 19:14 ` lsworkemail112
2012-09-29 19:15 ` Jason
2012-09-29 19:16 ` lsworkemail112
0 siblings, 2 replies; 20+ messages in thread
From: lsworkemail112 @ 2012-09-29 19:14 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 19:14 ` lsworkemail112
@ 2012-09-29 19:15 ` Jason
2012-09-29 19:17 ` lsworkemail112
2012-09-29 19:16 ` lsworkemail112
1 sibling, 1 reply; 20+ messages in thread
From: Jason @ 2012-09-29 19:15 UTC (permalink / raw)
On Sat, Sep 29, 2012 at 9: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...
Yea, seems reasonable enough.
Anyhow, it's merged here:
http://git.zx2c4.com/cgit/commit/?id=4608406c31900df07533bceef757692c966dd4eb
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 19:15 ` Jason
@ 2012-09-29 19:17 ` lsworkemail112
0 siblings, 0 replies; 20+ messages in thread
From: lsworkemail112 @ 2012-09-29 19:17 UTC (permalink / raw)
Great, thank you
On Sat, Sep 29, 2012 at 3:15 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Sat, Sep 29, 2012 at 9: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...
>
> Yea, seems reasonable enough.
>
> Anyhow, it's merged here:
> http://git.zx2c4.com/cgit/commit/?id=4608406c31900df07533bceef757692c966dd4eb
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 19:14 ` lsworkemail112
2012-09-29 19:15 ` Jason
@ 2012-09-29 19:16 ` lsworkemail112
1 sibling, 0 replies; 20+ messages in thread
From: lsworkemail112 @ 2012-09-29 19:16 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 18:43 ` lsworkemail112
2012-09-29 18:51 ` Jason
@ 2012-09-30 5:51 ` mailings
2012-09-30 17:28 ` lsworkemail112
2012-09-30 17:29 ` Jason
2012-10-01 13:56 ` webmaster
2 siblings, 2 replies; 20+ messages in thread
From: mailings @ 2012-09-30 5:51 UTC (permalink / raw)
On 29-09-12 20:43, Luke SanAntonio 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
I'd like to correct you on that.
Try running a server with many big git repositories with a cgit
interface on top, that is heavily used by people.
You'll really want to have caching.
Caching is not something I would like to see dropped or non-functional
> that with or without the cache,
> every cgit page I've ever come across seems to load in much less time
> than a second...
>
>
> Thanks for considering my patch =D
> - Luke
>
> On Sat, Sep 29, 2012 at 1:20 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> Hey Luke,
>>
>> Looks great, merged.
>>
>> My one concern, however, which might make me reconsider merging this
>> patch is -- what about the cache? Adding explicit seconds makes any
>> caching appear even more out of date than just minutes. But maybe this
>> isn't a big deal. What do you think?
>>
>> Jason
>
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit
>
--
Ferry Huberts
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-30 5:51 ` mailings
@ 2012-09-30 17:28 ` lsworkemail112
2012-09-30 17:29 ` Jason
1 sibling, 0 replies; 20+ messages in thread
From: lsworkemail112 @ 2012-09-30 17:28 UTC (permalink / raw)
fair enough... thanks for the correction =D - Luke
On Sep 30, 2012, at 1:51 AM, Ferry Huberts <mailings at hupie.com> wrote:
>
>
> On 29-09-12 20:43, Luke SanAntonio 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
>
>
> I'd like to correct you on that.
> Try running a server with many big git repositories with a cgit interface on top, that is heavily used by people.
> You'll really want to have caching.
> Caching is not something I would like to see dropped or non-functional
>
>> that with or without the cache,
>> every cgit page I've ever come across seems to load in much less time
>> than a second...
>>
>>
>> Thanks for considering my patch =D
>> - Luke
>>
>> On Sat, Sep 29, 2012 at 1:20 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>>> Hey Luke,
>>>
>>> Looks great, merged.
>>>
>>> My one concern, however, which might make me reconsider merging this
>>> patch is -- what about the cache? Adding explicit seconds makes any
>>> caching appear even more out of date than just minutes. But maybe this
>>> isn't a big deal. What do you think?
>>>
>>> Jason
>>
>> _______________________________________________
>> cgit mailing list
>> cgit at hjemli.net
>> http://hjemli.net/mailman/listinfo/cgit
>>
>
> --
> Ferry Huberts
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-30 5:51 ` mailings
2012-09-30 17:28 ` lsworkemail112
@ 2012-09-30 17:29 ` Jason
2012-09-30 17:40 ` mailings
2012-09-30 21:06 ` lsworkemail112
1 sibling, 2 replies; 20+ messages in thread
From: Jason @ 2012-09-30 17:29 UTC (permalink / raw)
On Sun, Sep 30, 2012 at 7:51 AM, Ferry Huberts <mailings at hupie.com> wrote:
>
> Try running a server with many big git repositories with a cgit interface on top, that is heavily used by people.
> You'll really want to have caching.
> Caching is not something I would like to see dropped or non-functional
Do you suppose that the second-level granularity has a negative impact
on cache behavior?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-30 17:29 ` Jason
@ 2012-09-30 17:40 ` mailings
2012-09-30 21:06 ` lsworkemail112
1 sibling, 0 replies; 20+ messages in thread
From: mailings @ 2012-09-30 17:40 UTC (permalink / raw)
On 30-09-12 19:29, Jason A. Donenfeld wrote:
> On Sun, Sep 30, 2012 at 7:51 AM, Ferry Huberts <mailings at hupie.com> wrote:
>>
>> Try running a server with many big git repositories with a cgit interface on top, that is heavily used by people.
>> You'll really want to have caching.
>> Caching is not something I would like to see dropped or non-functional
>
>
> Do you suppose that the second-level granularity has a negative impact
> on cache behavior?
>
what do you mean?
--
Ferry Huberts
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-30 17:29 ` Jason
2012-09-30 17:40 ` mailings
@ 2012-09-30 21:06 ` lsworkemail112
2012-09-30 21:33 ` Jason
1 sibling, 1 reply; 20+ messages in thread
From: lsworkemail112 @ 2012-09-30 21:06 UTC (permalink / raw)
do you mean performance, or are you saying the system
might get confused? or neither? or both?
On Sun, Sep 30, 2012 at 1:29 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Sun, Sep 30, 2012 at 7:51 AM, Ferry Huberts <mailings at hupie.com> wrote:
>>
>> Try running a server with many big git repositories with a cgit interface on top, that is heavily used by people.
>> You'll really want to have caching.
>> Caching is not something I would like to see dropped or non-functional
>
>
> Do you suppose that the second-level granularity has a negative impact
> on cache behavior?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-30 21:06 ` lsworkemail112
@ 2012-09-30 21:33 ` Jason
2012-10-01 6:12 ` mailings
0 siblings, 1 reply; 20+ messages in thread
From: Jason @ 2012-09-30 21:33 UTC (permalink / raw)
So much confusion. I'll reexplain:
Before:
You visit a page with cache turned on. It says "modified 1 minute
ago".. You visit the page again a little later. It says "modified 1
minute ago". You don't really notice, because a minute is a longish
amount of time.
After:
You visit a page with cache turned on. It says "modified 7 seconds
ago". You visit the page again a little later. It says "modified 7
seconds ago". You do notice, because you're more intimately aware of
the fact that a minute after seven seconds is more than seven seconds.
This is the only concern. A bit silly perhaps.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-30 21:33 ` Jason
@ 2012-10-01 6:12 ` mailings
2012-10-02 1:46 ` lsworkemail112
0 siblings, 1 reply; 20+ messages in thread
From: mailings @ 2012-10-01 6:12 UTC (permalink / raw)
On 30-09-12 23:33, Jason A. Donenfeld wrote:
> So much confusion. I'll reexplain:
>
> Before:
> You visit a page with cache turned on. It says "modified 1 minute
> ago".. You visit the page again a little later. It says "modified 1
> minute ago". You don't really notice, because a minute is a longish
> amount of time.
>
> After:
> You visit a page with cache turned on. It says "modified 7 seconds
> ago". You visit the page again a little later. It says "modified 7
> seconds ago". You do notice, because you're more intimately aware of
> the fact that a minute after seven seconds is more than seven seconds.
>
>
> This is the only concern. A bit silly perhaps.
>
I don't care about seconds resolution.
The cache is exactly the reason we should not have seconds resolution
because it provokes all kinds of confusion (like this discussion)
--
Ferry Huberts
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-10-01 6:12 ` mailings
@ 2012-10-02 1:46 ` lsworkemail112
2012-10-02 2:04 ` Jason
0 siblings, 1 reply; 20+ messages in thread
From: lsworkemail112 @ 2012-10-02 1:46 UTC (permalink / raw)
At this point it might be best if we just drop the patch... There is no reason
to keep it around if everyone seems to be having doubts and questions...
I am starting to have doubts myself, and there really isn't any reason to keep
it around, other than looks... Sorry for the trouble -- Luke
On Mon, Oct 1, 2012 at 2:12 AM, Ferry Huberts <mailings at hupie.com> wrote:
>
>
> On 30-09-12 23:33, Jason A. Donenfeld wrote:
>>
>> So much confusion. I'll reexplain:
>>
>> Before:
>> You visit a page with cache turned on. It says "modified 1 minute
>> ago".. You visit the page again a little later. It says "modified 1
>> minute ago". You don't really notice, because a minute is a longish
>> amount of time.
>>
>> After:
>> You visit a page with cache turned on. It says "modified 7 seconds
>> ago". You visit the page again a little later. It says "modified 7
>> seconds ago". You do notice, because you're more intimately aware of
>> the fact that a minute after seven seconds is more than seven seconds.
>>
>>
>> This is the only concern. A bit silly perhaps.
>>
>
> I don't care about seconds resolution.
> The cache is exactly the reason we should not have seconds resolution
> because it provokes all kinds of confusion (like this discussion)
>
>
> --
> Ferry Huberts
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Added code to output the age as seconds instead of "0 min."
2012-09-29 18:43 ` lsworkemail112
2012-09-29 18:51 ` Jason
2012-09-30 5:51 ` mailings
@ 2012-10-01 13:56 ` webmaster
2 siblings, 0 replies; 20+ messages in thread
From: webmaster @ 2012-10-01 13:56 UTC (permalink / raw)
For what it's worth, some of run run fairly large Git installations with
busy cgit instances. We are very concerned about performance :)
Thanks for not forgetting us.
Denis
On 09/29/2012 02:43 PM, Luke SanAntonio 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...
>
>
> Thanks for considering my patch =D
> - Luke
>
> On Sat, Sep 29, 2012 at 1:20 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> Hey Luke,
>>
>> Looks great, merged.
>>
>> My one concern, however, which might make me reconsider merging this
>> patch is -- what about the cache? Adding explicit seconds makes any
>> caching appear even more out of date than just minutes. But maybe this
>> isn't a big deal. What do you think?
>>
>> Jason
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit
>
--
--
Eclipse Webmaster -- http://www.eclipse.org/
http://wiki.eclipse.org/Webmaster_FAQ
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-10-02 2:08 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-18 20:37 [PATCH] Added code to output the age as seconds instead of "0 min." lsworkemail112
2012-09-27 1:39 Maintaining My Own Cgit Tree Jason
2012-09-29 0:30 ` [PATCH] Added code to output the age as seconds instead of "0 min." lsworkemail112
2012-09-29 5:20 ` Jason
2012-09-29 18:43 ` lsworkemail112
2012-09-29 18:51 ` Jason
2012-09-29 19:14 ` lsworkemail112
2012-09-29 19:15 ` Jason
2012-09-29 19:17 ` lsworkemail112
2012-09-29 19:16 ` lsworkemail112
2012-09-30 5:51 ` mailings
2012-09-30 17:28 ` lsworkemail112
2012-09-30 17:29 ` Jason
2012-09-30 17:40 ` mailings
2012-09-30 21:06 ` lsworkemail112
2012-09-30 21:33 ` Jason
2012-10-01 6:12 ` mailings
2012-10-02 1:46 ` lsworkemail112
2012-10-02 2:04 ` Jason
2012-10-02 2:08 ` lsworkemail112
2012-10-01 13:56 ` webmaster
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).