Maintaining My Own Cgit Tree

Maintaining My Own Cgit Tree

[Jason]

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

Maintaining My Own Cgit Tree

[william.bell]

Wonderful


On 27/09/2012 03:39, Jason A. Donenfeld wrote:
> 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
>
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit
>

Maintaining My Own Cgit Tree

[Tobias.Bieniek]

Thanks Jason. I think that is a good idea. Too bad that Lars did not
leave any information... I've forwarded my three small patches too you
and hope that you will find them useful.

Turbo


2012/9/27 William Bell <william.bell at frog.za.net>:
> Wonderful
>
>
>
> On 27/09/2012 03:39, Jason A. Donenfeld wrote:
>>
>> 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
>>
>> _______________________________________________
>> cgit mailing list
>> cgit at hjemli.net
>> http://hjemli.net/mailman/listinfo/cgit
>>
>
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit

Maintaining My Own Cgit Tree

[webmaster]

+1

On 09/27/2012 12:22 AM, William Bell wrote:
> Wonderful
>
>
> On 27/09/2012 03:39, Jason A. Donenfeld wrote:
>> 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
>>


-- 
--
Eclipse Webmaster -- http://www.eclipse.org/
http://wiki.eclipse.org/Webmaster_FAQ

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

[lsworkemail112]

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

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

[Jason]

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

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

[lsworkemail112]

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

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

[Jason]

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.

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

[lsworkemail112]

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.

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

[Jason]

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

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

[lsworkemail112]

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

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

[lsworkemail112]

"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.

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

[mailings]

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

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

[lsworkemail112]

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

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

[Jason]

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?

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

[mailings]

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

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

[lsworkemail112]

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?

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

[Jason]

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.

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

[mailings]

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

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

[lsworkemail112]

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

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

[Jason]

Agreed. Dropped.

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

[lsworkemail112]

Cool...

On Mon, Oct 1, 2012 at 10:04 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Agreed. Dropped.

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

[webmaster]

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

[PATCH 1/2] add git config parsing during scan-path

[jamie.couture]

Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
---
 cgit.c      |  3 +++
 cgit.h      |  1 +
 scan-tree.c | 19 +++++++++++++++----
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/cgit.c b/cgit.c
index 1ec02e7..910bf1d 100644
--- a/cgit.c
+++ b/cgit.c
@@ -183,6 +183,8 @@ void config_cb(const char *name, const char *value)
 		ctx.cfg.enable_subject_links = atoi(value);
 	else if (!strcmp(name, "enable-tree-linenumbers"))
 		ctx.cfg.enable_tree_linenumbers = atoi(value);
+	else if (!strcmp(name, "enable-git-config"))
+		ctx.cfg.enable_git_config = atoi(value);
 	else if (!strcmp(name, "max-stats"))
 		ctx.cfg.max_stats = cgit_find_stats_period(value, NULL);
 	else if (!strcmp(name, "cache-size"))
@@ -348,6 +350,7 @@ static void prepare_context(struct cgit_context *ctx)
 	ctx->cfg.enable_gitweb_section = 1;
 	ctx->cfg.enable_http_clone = 1;
 	ctx->cfg.enable_tree_linenumbers = 1;
+	ctx->cfg.enable_git_config = 0;
 	ctx->cfg.max_repo_count = 50;
 	ctx->cfg.max_commit_count = 50;
 	ctx->cfg.max_lock_attempts = 5;
diff --git a/cgit.h b/cgit.h
index 79ba7ad..4ac6f80 100644
--- a/cgit.h
+++ b/cgit.h
@@ -211,6 +211,7 @@ struct cgit_config {
 	int enable_remote_branches;
 	int enable_subject_links;
 	int enable_tree_linenumbers;
+	int enable_git_config;
 	int local_time;
 	int max_atom_items;
 	int max_repo_count;
diff --git a/scan-tree.c b/scan-tree.c
index 6d1941e..7e711d5 100644
--- a/scan-tree.c
+++ b/scan-tree.c
@@ -67,7 +67,14 @@ static int gitweb_config(const char *key, const char *value, void *cb)
 	return 0;
 }
 
+static int cgit_repo_config(const char *key, const char *value, void *cb)
+{
+	if (!prefixcmp(key, "cgit.")) {
+		config_fn(repo, key + 5, value);
+	}
 
+	return 0;
+}
 
 static char *xstrrchr(char *s, char *from, int c)
 {
@@ -166,10 +173,14 @@ static void add_repo(const char *base, const char *path, repo_config_fn fn)
 		}
 	}
 
-	p = fmt("%s/cgitrc", path);
-	if (!stat(p, &st)) {
-		config_fn = fn;
-		parse_configfile(xstrdup(p), &repo_config);
+	config_fn = fn;
+	if (ctx.cfg.enable_git_config) {
+		git_config_from_file(cgit_repo_config, fmt("%s/config", path), NULL);
+	} else {
+		p = fmt("%s/cgitrc", path);
+		if (!stat(p, &st)) {
+			parse_configfile(xstrdup(p), &repo_config);
+		}
 	}
 
 	free(rel);
-- 
1.7.11.4

[PATCH 2/2] update documentation

[jamie.couture]

- include examples to support gitolite2 and gitolite3
 .gitolite.rc

Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
---
 cgitrc.5.txt | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/cgitrc.5.txt b/cgitrc.5.txt
index 902fff3..fadbbbc 100644
--- a/cgitrc.5.txt
+++ b/cgitrc.5.txt
@@ -110,6 +110,13 @@ enable-filter-overrides::
 	Flag which, when set to "1", allows all filter settings to be
 	overridden in repository-specific cgitrc files. Default value: none.
 
+enable-git-config::
+    Flag which, when set to "1", will allow cgit to use git config to set
+    any repo specific settings. Please read <<repo-settings>> to learn more
+    about which settings are available. This option is used in conjunction with
+    "scan-path" to override _repo._ settings. Please read <<git-config>> to
+    learn how to integrate with gitolite.  Default value: "0".
+
 enable-gitweb-desc::
 	If set to "1" and scan-path is enabled, we first check each repository
 	for the git config value "gitweb.description" to determine the owner.
@@ -394,6 +401,7 @@ virtual-root::
 	NOTE: cgit has recently learned how to use PATH_INFO to achieve the
 	same kind of virtual urls, so this option will probably be deprecated.
 
+[[repo-settings]]
 REPOSITORY SETTINGS
 -------------------
 repo.about-filter::
@@ -509,6 +517,45 @@ options are only acknowledged in repo-specific config files when
 Note: the "repo." prefix is dropped from the option names in repo-specific
 config files, e.g. "repo.desc" becomes "desc".
 
+[[git-config]]
+REPOSITORY-SPECIFIC GIT CONFIG
+------------------------------
+When "scan-path" is used to auto-discover repositories "enable-git-config" will
+allow cgit to look at git config to obtain repo specific settings.
+Configuration is best managed by gitolite's big-config. Please read more about
+http://sitaramc.github.com/gitolite/confother_.html[gitolite repo specific
+commands here].
+
+.Example gitolite.conf
+......
+repo aproject
+    RW+ = bob
+    config repo.section = applications
+    config repo.defbranch = development
+    aproject "Bob McPerson <bob.mcperson at example.com>" = "Foo description"
+
+repo bproject
+    RW+ = bob
+    config repo.section = test
+    config repo.logo = /cgit-data/logo.png
+    bproject "Bob McPerson <bob.mcperson at example.com>" = "Bar description"
+......
+
+[IMPORTANT]
+Unlike cgitrc, we're looking for repo settings with prefix "cgit.". That is,
+all options named 'repo.XY' above have to be called 'cgit.XY'.  Remember to
+edit _.gitolite.rc_ and add the following:
+
+.gitolite 3 users
+.......
+$GIT_CONFIG_KEYS = "cgit\..*"
+.......
+
+.gitolite 2 users
+.......
+$GL_GITCONFIG_KEYS = "cgit\..*"
+.......
+
 
 FILTER API
 ----------
-- 
1.7.11.4

[PATCH 2/2] update documentation

[@ 2012-10-08 21:05 UTC (permalink / raw)]

Am 08.10.2012 18:48, schrieb Jamie Couture:
> - include examples to support gitolite2 and gitolite3
>  .gitolite.rc
>
> Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
> ---
>  cgitrc.5.txt | 47 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>
> diff --git a/cgitrc.5.txt b/cgitrc.5.txt
> index 902fff3..fadbbbc 100644
> --- a/cgitrc.5.txt
> +++ b/cgitrc.5.txt
> @@ -110,6 +110,13 @@ enable-filter-overrides::
>  	Flag which, when set to "1", allows all filter settings to be
>  	overridden in repository-specific cgitrc files. Default value: 
> none.
>
> +enable-git-config::
> +    Flag which, when set to "1", will allow cgit to use git config 
> to set
> +    any repo specific settings. Please read <<repo-settings>> to 
> learn more
> +    about which settings are available. This option is used in 
> conjunction with
> +    "scan-path" to override _repo._ settings. Please read 
> <<git-config>> to
> +    learn how to integrate with gitolite.  Default value: "0".
> +
>  enable-gitweb-desc::
>  	If set to "1" and scan-path is enabled, we first check each 
> repository
>  	for the git config value "gitweb.description" to determine the 
> owner.
> @@ -394,6 +401,7 @@ virtual-root::
>  	NOTE: cgit has recently learned how to use PATH_INFO to achieve the
>  	same kind of virtual urls, so this option will probably be 
> deprecated.
>
> +[[repo-settings]]
>  REPOSITORY SETTINGS
>  -------------------
>  repo.about-filter::
> @@ -509,6 +517,45 @@ options are only acknowledged in repo-specific
> config files when
>  Note: the "repo." prefix is dropped from the option names in 
> repo-specific
>  config files, e.g. "repo.desc" becomes "desc".
>
> +[[git-config]]
> +REPOSITORY-SPECIFIC GIT CONFIG
> +------------------------------
> +When "scan-path" is used to auto-discover repositories 
> "enable-git-config" will
> +allow cgit to look at git config to obtain repo specific settings.
> +Configuration is best managed by gitolite's big-config. Please read 
> more about
> +http://sitaramc.github.com/gitolite/confother_.html[gitolite repo 
> specific
> +commands here].
> +
> +.Example gitolite.conf
> +......
> +repo aproject
> +    RW+ = bob
> +    config repo.section = applications
> +    config repo.defbranch = development
> +    aproject "Bob McPerson <bob.mcperson at example.com>" = "Foo 
> description"
> +
> +repo bproject
> +    RW+ = bob
> +    config repo.section = test
> +    config repo.logo = /cgit-data/logo.png
> +    bproject "Bob McPerson <bob.mcperson at example.com>" = "Bar 
> description"
> +......
> +
> +[IMPORTANT]
> +Unlike cgitrc, we're looking for repo settings with prefix "cgit.". 
> That is,
> +all options named 'repo.XY' above have to be called 'cgit.XY'.  
> Remember to
> +edit _.gitolite.rc_ and add the following:
> +
> +.gitolite 3 users
> +.......
> +$GIT_CONFIG_KEYS = "cgit\..*"
> +.......
> +
> +.gitolite 2 users
> +.......
> +$GL_GITCONFIG_KEYS = "cgit\..*"
> +.......
> +
>
>  FILTER API
>  ----------

[PATCH 2/2] update documentation

[@ 2012-10-08 21:18 UTC (permalink / raw)]

(Sorry for the first empty mail--hit the send button with my fat 
fingers by accident)

I just wanted to point out that some changes I did were for a reason:

> +Configuration is best managed by gitolite's big-config. Please read 
> more about
> +http://sitaramc.github.com/gitolite/confother_.html[gitolite repo 
> specific
> +commands here].

The term "big config" is outdated--and the link is dead.

> +    aproject "Bob McPerson <bob.mcperson at example.com>" = "Foo 
> description"

This syntax does not work anymore. Also gitolite seems to forbid '<' 
and '>' in config values (couldn't get a reasonable answer on this in 
IRC)

Regards,
Ren?

[PATCH] repolist pagination changes

[jamie.couture]

bold the current page we're viewing

Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
---
 cgit.css      |  4 ++++
 ui-repolist.c | 11 +++++++----
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/cgit.css b/cgit.css
index 651a320..54da076 100644
--- a/cgit.css
+++ b/cgit.css
@@ -548,6 +548,10 @@ div#cgit div.pager a {
 	margin: 0em 0.5em;
 }
 
+div#cgit div.pager .current {
+	font-weight: bold;
+}
+
 div#cgit span.age-mins {
 	font-weight: bold;
 	color: #080;
diff --git a/ui-repolist.c b/ui-repolist.c
index 943eaab..46cbacf 100644
--- a/ui-repolist.c
+++ b/ui-repolist.c
@@ -123,11 +123,14 @@ void print_header(int columns)
 
 void print_pager(int items, int pagelen, char *search, char *sort)
 {
-	int i;
+	int i, ofs;
+	char *class = NULL;
 	html("<div class='pager'>");
-	for(i = 0; i * pagelen < items; i++)
-		cgit_index_link(fmt("[%d]", i+1), fmt("Page %d", i+1), NULL,
-				search, sort, i * pagelen);
+	for(i = 0, ofs = 0; ofs < items; i++, ofs = i * pagelen) {
+		class = (ctx.qry.ofs == ofs) ? "current" : NULL;
+		cgit_index_link(fmt("[%d]", i+1), fmt("Page %d", i+1), class,
+				search, sort, ofs);
+	}
 	html("</div>");
 }
 
-- 
1.7.11.4

[PATCH] repolist pagination changes

[Jason]

Looks great. Committed here:

http://git.zx2c4.com/cgit/commit/?id=4675b91211fe3119a0def539521ac759b3fb57d0

[PATCH] add tag target to generate ctags

[jamie.couture]

Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
---
 Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index eac24ad..1e34129 100644
--- a/Makefile
+++ b/Makefile
@@ -73,6 +73,7 @@ ifndef V
 	QUIET_SUBDIR0  = + at subdir=
 	QUIET_SUBDIR1  = ;$(NO_SUBDIR) echo '   ' SUBDIR $$subdir; \
 			 $(MAKE) $(PRINT_DIR) -C $$subdir
+	QUIET_TAGS     = @echo '   ' TAGS $@;
 endif
 
 #
@@ -124,7 +125,7 @@ endif
 
 .PHONY: all libgit test install uninstall clean force-version get-git \
 	doc clean-doc install-doc install-man install-html install-pdf \
-	uninstall-doc uninstall-man uninstall-html uninstall-pdf
+	uninstall-doc uninstall-man uninstall-html uninstall-pdf tags
 
 all: cgit
 
@@ -242,3 +243,6 @@ clean-doc:
 
 get-git:
 	curl $(GIT_URL) | tar -xjf - && rm -rf git && mv git-$(GIT_VER) git
+
+tags:
+	$(QUIET_TAGS)find . -name '*.[ch]' | xargs ctags
-- 
1.7.11.4

[PATCH] add tag target to generate ctags

[Jason]

Seems fairly uncontroversial. Committed:
http://git.zx2c4.com/cgit/commit/?id=6419c9b57c33a8a26d2775f01629f899afb61026

[PATCH] add git config parsing during scan-path

[jamie.couture]

Signed-off-by: Jamie Couture <jamie.couture at gmail.com>
---
 cgit.c      |  3 +++
 cgit.h      |  1 +
 scan-tree.c | 18 ++++++++++++------
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/cgit.c b/cgit.c
index 1ec02e7..910bf1d 100644
--- a/cgit.c
+++ b/cgit.c
@@ -183,6 +183,8 @@ void config_cb(const char *name, const char *value)
 		ctx.cfg.enable_subject_links = atoi(value);
 	else if (!strcmp(name, "enable-tree-linenumbers"))
 		ctx.cfg.enable_tree_linenumbers = atoi(value);
+	else if (!strcmp(name, "enable-git-config"))
+		ctx.cfg.enable_git_config = atoi(value);
 	else if (!strcmp(name, "max-stats"))
 		ctx.cfg.max_stats = cgit_find_stats_period(value, NULL);
 	else if (!strcmp(name, "cache-size"))
@@ -348,6 +350,7 @@ static void prepare_context(struct cgit_context *ctx)
 	ctx->cfg.enable_gitweb_section = 1;
 	ctx->cfg.enable_http_clone = 1;
 	ctx->cfg.enable_tree_linenumbers = 1;
+	ctx->cfg.enable_git_config = 0;
 	ctx->cfg.max_repo_count = 50;
 	ctx->cfg.max_commit_count = 50;
 	ctx->cfg.max_lock_attempts = 5;
diff --git a/cgit.h b/cgit.h
index 79ba7ad..4ac6f80 100644
--- a/cgit.h
+++ b/cgit.h
@@ -211,6 +211,7 @@ struct cgit_config {
 	int enable_remote_branches;
 	int enable_subject_links;
 	int enable_tree_linenumbers;
+	int enable_git_config;
 	int local_time;
 	int max_atom_items;
 	int max_repo_count;
diff --git a/scan-tree.c b/scan-tree.c
index 6d1941e..0dbfc13 100644
--- a/scan-tree.c
+++ b/scan-tree.c
@@ -64,11 +64,13 @@ static int gitweb_config(const char *key, const char *value, void *cb)
 		desc = xstrdup(value);
 	else if (ctx.cfg.enable_gitweb_section && !strcmp(key, "gitweb.category"))
 		section = xstrdup(value);
+	else if (!prefixcmp(key, "cgit.")) {
+		config_fn(repo, key + 5, value);
+	}
+
 	return 0;
 }
 
-
-
 static char *xstrrchr(char *s, char *from, int c)
 {
 	while (from >= s && *from != c)
@@ -166,10 +168,14 @@ static void add_repo(const char *base, const char *path, repo_config_fn fn)
 		}
 	}
 
-	p = fmt("%s/cgitrc", path);
-	if (!stat(p, &st)) {
-		config_fn = fn;
-		parse_configfile(xstrdup(p), &repo_config);
+	config_fn = fn;
+	if (ctx.cfg.enable_git_config) {
+		git_config_from_file(gitweb_config, fmt("%s/config", path), NULL);
+	} else {
+		p = fmt("%s/cgitrc", path);
+		if (!stat(p, &st)) {
+			parse_configfile(xstrdup(p), &repo_config);
+		}
 	}
 
 	free(rel);
-- 
1.7.11.4

[PATCH] add git config parsing during scan-path

[Jason]

On Tue, Oct 9, 2012 at 12:56 PM, Jamie Couture <jamie.couture at gmail.com> wrote:
> +       else if (!prefixcmp(key, "cgit.")) {
> +               config_fn(repo, key + 5, value);
> +       }
> +

This check isn't sufficient, since if the enable_git_config is not
enabled, but the existing gitweb_section/description settings are
enabled, then enable_git_config becomes implicitly enabled.

But maybe this points to a larger issue: too many settings here. It
seems like we might be best with a single enable_git_config setting
that takes into account known gitweb.* as well as merging cgit.*.

OTOH, maybe it's better to just add a defbranch key to the gitweb
namespace. There already exists category, owner, and description. If
we add defbranch, what other features are folks actually going to want
to be configurable within gitconfig?

If there are additional keys that people want, then I'm fine having
the gitweb namespace as well as the cgit namespace, but if this is
actually just in the name of defbranch, there might be a simpler
solution.

Maintaining My Own Cgit Tree

[mailings]

On 27-09-12 03:39, Jason A. Donenfeld wrote:
> 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


There was talk of forking cgit before and then Lars showed up again.

I dislike forking very much, but since Lars has been MIA for so long, I 
think it's for the best.

So I applaud you for taking on the maintainer role ;-)

I just sent out my pending patches again, rebased on your master.

grtz


>
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit
>

-- 
Ferry Huberts

Maintaining My Own Cgit Tree

[Jason]

On Tue, Oct 9, 2012 at 1:15 PM, Ferry Huberts <mailings at hupie.com> wrote:
> There was talk of forking cgit before and then Lars showed up again.
>
> I dislike forking very much, but since Lars has been MIA for so long, I
> think it's for the best.

Just to reiterate though, this isn't meant as a fork. It's a temporary
stewardship until Lars / Aragorn shows up again. Of course, in the
event that he disappears forever, then sure, it'll be for real.


>
> So I applaud you for taking on the maintainer role ;-)
>

Thanks : )