' \ -e '^Last-Modified: ' \ -e ^'Expires: ' >expect $ seq 50000 | dd bs=8192 | parallel -j200 "diff -u expect <(./cgit | grep -v -e '^

' \ -e '^Last-Modified: ' \ -e ^'Expires: ') || echo BAD" This printed the fail message several times without ever printing "BAD". Signed-off-by: John Keeping --- On Tue, Mar 03, 2015 at 04:40:01PM +0100, Jason A. Donenfeld wrote: > Feel free to send a patch, John. Here it is! cache.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/cache.c b/cache.c index 801e63f..900b161 100644 --- a/cache.c +++ b/cache.c @@ -161,10 +161,23 @@ static int close_lock(struct cache_slot *slot) */ static int lock_slot(struct cache_slot *slot) { - slot->lock_fd = open(slot->lock_name, O_RDWR | O_CREAT | O_EXCL, + struct flock lock = { + .l_type = F_WRLCK, + .l_whence = SEEK_SET, + .l_start = 0, + .l_len = 0, + }; + + slot->lock_fd = open(slot->lock_name, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); if (slot->lock_fd == -1) return errno; + if (fcntl(slot->lock_fd, F_SETLK, &lock) < 0) { + int saved_errno = errno; + close(slot->lock_fd); + slot->lock_fd = -1; + return saved_errno; + } if (xwrite(slot->lock_fd, slot->key, slot->keylen + 1) < 0) return errno; return 0; -- 2.3.1.308.g754cd77 From Jason at zx2c4.com Tue Mar 3 23:56:11 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Mar 2015 23:56:11 +0100 Subject: cache issue In-Reply-To: <20150303192231.GO890@serenity.lan> References: <20140323140642.GF1223@lemonhead.scabb> <20150228123719.GL890@serenity.lan> <20150301193600.GM890@serenity.lan> <20150303093124.GN890@serenity.lan> <20150303192231.GO890@serenity.lan> Message-ID: Thanks! Merged. It would be nice to see a test case built out of the example you gave in the commit message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason at zx2c4.com Tue Mar 3 23:59:20 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Mar 2015 23:59:20 +0100 Subject: JSON interface In-Reply-To: <118752262.FIjLZQZKii@145523a> References: <118752262.FIjLZQZKii@145523a> Message-ID: This would indeed be quite nice. I'll look into it for 0.12. Currently I'm just running a python web app on top of it to do the trick. Not great, but it gets the job done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason at zx2c4.com Wed Mar 4 00:01:13 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 4 Mar 2015 00:01:13 +0100 Subject: 0.11.1 coming soon Message-ID: Hi guys, The Gentoo infra team has been sending me bug reports that I've been fixing in the master branch. Gentoo is in the process of rolling out a cgit instance on http://gitweb.gentoo.org/ , which is actually some pretty significant progress for the project, considering CVS is still used for all the packages... Anyway, I'm likely going to be releasing an 0.11.1 soon containing some fixes for them. If there are any nits you'd like to get in before then, please send them onward. Thanks, Jason From john at keeping.me.uk Wed Mar 4 00:43:42 2015 From: john at keeping.me.uk (John Keeping) Date: Tue, 3 Mar 2015 23:43:42 +0000 Subject: cache issue In-Reply-To: References: <20140323140642.GF1223@lemonhead.scabb> <20150228123719.GL890@serenity.lan> <20150301193600.GM890@serenity.lan> <20150303093124.GN890@serenity.lan> <20150303192231.GO890@serenity.lan> Message-ID: <20150303234342.GS890@serenity.lan> On Tue, Mar 03, 2015 at 11:56:11PM +0100, Jason A. Donenfeld wrote: > Thanks! Merged. It would be nice to see a test case built out of the > example you gave in the commit message. It has to run for a couple of minutes to get sensible results. I guess we could introduce an EXPENSIVE prerequisite in the same way Git does, but I'm not sure how often anyone would run the test suite with that turned on. From chris.burroughs at gmail.com Wed Mar 4 17:10:03 2015 From: chris.burroughs at gmail.com (Chris Burroughs) Date: Wed, 04 Mar 2015 11:10:03 -0500 Subject: JSON interface In-Reply-To: References: <118752262.FIjLZQZKii@145523a> Message-ID: <54F72E5B.50601@gmail.com> What python web app? I've been looking into running an application (chef-guard) that only works with the github api and trying to figure out a reasonable workaround. On 03/03/2015 05:59 PM, Jason A. Donenfeld wrote: > This would indeed be quite nice. I'll look into it for 0.12. > > Currently I'm just running a python web app on top of it to do the trick. > Not great, but it gets the job done. > > > > _______________________________________________ > CGit mailing list > CGit at lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/cgit > From Jason at zx2c4.com Wed Mar 4 17:12:42 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 4 Mar 2015 17:12:42 +0100 Subject: JSON interface In-Reply-To: <54F72E5B.50601@gmail.com> References: <118752262.FIjLZQZKii@145523a> <54F72E5B.50601@gmail.com> Message-ID: The one behind this: http://git.zx2c4.com/json/projects and http://git.zx2c4.com/json/random-code It's like 20 lines long and sort of trivial, not worth cleaning up for release. From r at uzy.me Thu Mar 5 09:22:55 2015 From: r at uzy.me (Pablo Rauzy) Date: Thu, 05 Mar 2015 09:22:55 +0100 Subject: Description for section and link for repos Message-ID: <87mw3rvoo0.fsf@uzy.me> Hello, I'm a new cgit user (I expect there will be a lot of us in the coming weeks, with Gitorious shuting down), and I have two questions/requests. But first, I would like to say that cgit is awesome it was easy to install and run, and has a very small footprint, thanks a lot to the developers and maintainers. My first question is about sections. I would like to be able to add a title and a little description for each section, just like I can with the cgit.desc configuration for each the git repos. Example : http://clandest.in/sensi Here I would like the title to be "clandest.in / sensi" rather than just "clandest.in", and I would like the description to be "SEN Security Inspector" rather than the root description. My second question is about repository. I would like to add title and a link to a project home page somewhere else than on the logo. Example : http://clandest.in/sensi/finja Here I would like the title to be "clandest.in / sensi / finja" rather than "index : finja", and I would like to add a tab "homepage" after "diff" which would link to http://pablo.rauzy.name/sensi/finja.html in this example. Is what I'm looking for already possible? If yes, how? If not, I think it would be a nice addition. I don't have a lot of time right now (I kind of have a PhD thesis to write?) but if it's not implemented by someone else by the time I find a few hours to explore cgit codebase and add these features, would such a patch be welcome? Thanks again for the nice piece of software that is cgit! Cheers, -- Pablo Rauzy. http://pablo.rauzy.name/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From john at keeping.me.uk Thu Mar 5 10:30:30 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 09:30:30 +0000 Subject: Description for section and link for repos In-Reply-To: <87mw3rvoo0.fsf@uzy.me> References: <87mw3rvoo0.fsf@uzy.me> Message-ID: <20150305093030.GA1369@serenity.lan> On Thu, Mar 05, 2015 at 09:22:55AM +0100, Pablo Rauzy wrote: > My first question is about sections. > I would like to be able to add a title and a little description for each > section, just like I can with the cgit.desc configuration for each the > git repos. > > Example : http://clandest.in/sensi > Here I would like the title to be "clandest.in / sensi" rather than just > "clandest.in", and I would like the description to be "SEN Security > Inspector" rather than the root description. Are you currently using "section-from-path"? If you use the "repo.section" configuration option then you can name the sections however you want, but this is not possible if you are generating the sections automatically. If you're combining CGit with Gitolite you may be able to avoid listing repositories twice by using CGit's "enable-git-config" option to configure the "repo.section" variable (I'm not sure if you can set a config variable on a group of repositories in Gitolite, but I think you should be able to). > My second question is about repository. > I would like to add title and a link to a project home page somewhere > else than on the logo. > > Example : http://clandest.in/sensi/finja > Here I would like the title to be "clandest.in / sensi / finja" rather > than "index : finja", and I would like to add a tab "homepage" after > "diff" which would link to http://pablo.rauzy.name/sensi/finja.html in > this example. > > > Is what I'm looking for already possible? If yes, how? If not, I think > it would be a nice addition. I don't think this is currently possible. Note that the word "index" is actually a link to the list of repositories. For the "homepage" link, have you considered simply adding a link to the repository's readme (on the about tab)? I thought there was a way to make the "about" tab the default instead of the "summary" tab, but I can't find it when I go looking so I must be wrong about that. From r at uzy.me Thu Mar 5 10:51:09 2015 From: r at uzy.me (Pablo Rauzy) Date: Thu, 05 Mar 2015 10:51:09 +0100 Subject: Description for section and link for repos In-Reply-To: <20150305093030.GA1369@serenity.lan> References: <87mw3rvoo0.fsf@uzy.me> <20150305093030.GA1369@serenity.lan> Message-ID: <87lhjbvkky.fsf@uzy.me> Hello again, and thanks for your quick response. On 2015-03-05, John Keeping wrote: > On Thu, Mar 05, 2015 at 09:22:55AM +0100, Pablo Rauzy wrote: >> My first question is about sections. >> I would like to be able to add a title and a little description for each >> section, just like I can with the cgit.desc configuration for each the >> git repos. >> >> Example : http://clandest.in/sensi >> Here I would like the title to be "clandest.in / sensi" rather than just >> "clandest.in", and I would like the description to be "SEN Security >> Inspector" rather than the root description. > > Are you currently using "section-from-path"? If you use the > "repo.section" configuration option then you can name the sections > however you want, but this is not possible if you are generating the > sections automatically. Indeed I am using section-from-path, but the name of the sections are just fine. What I was looking for is the possibility to for instance make cgit using a file called "description" in the directory that it makes a section as description of that section. > If you're combining CGit with Gitolite you may be able to avoid listing > repositories twice by using CGit's "enable-git-config" option to > configure the "repo.section" variable (I'm not sure if you can set a > config variable on a group of repositories in Gitolite, but I think you > should be able to). I'm not using Gitolite. >> My second question is about repository. >> I would like to add title and a link to a project home page somewhere >> else than on the logo. >> >> Example : http://clandest.in/sensi/finja >> Here I would like the title to be "clandest.in / sensi / finja" rather >> than "index : finja", and I would like to add a tab "homepage" after >> "diff" which would link to http://pablo.rauzy.name/sensi/finja.html in >> this example. >> >> >> Is what I'm looking for already possible? If yes, how? If not, I think >> it would be a nice addition. > > I don't think this is currently possible. Note that the word "index" is > actually a link to the list of repositories. Yes I noticed that, but I find it less nice than having the root-title for the link. > For the "homepage" link, have you considered simply adding a link to the > repository's readme (on the about tab)? I thought there was a way to > make the "about" tab the default instead of the "summary" tab, but I > can't find it when I go looking so I must be wrong about that. That is exactly what I did for now. Maybe it is enough. I'll see with the time how much I like it this way :). FWIW, here is the filter I wrote to make link clickable in plaintext READMEs: http://paste.fulltxt.net/LKdVjbHaY (it is quick and dirty, it simply considers that anything between < and > and starting with "http" is a link). Thanks again for your really quick answer! Cheers, -- Pablo Rauzy. http://pablo.rauzy.name/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From john at keeping.me.uk Thu Mar 5 10:57:40 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 09:57:40 +0000 Subject: Description for section and link for repos In-Reply-To: <87lhjbvkky.fsf@uzy.me> References: <87mw3rvoo0.fsf@uzy.me> <20150305093030.GA1369@serenity.lan> <87lhjbvkky.fsf@uzy.me> Message-ID: <20150305095739.GB1369@serenity.lan> On Thu, Mar 05, 2015 at 10:51:09AM +0100, Pablo Rauzy wrote: > Hello again, and thanks for your quick response. > > On 2015-03-05, John Keeping wrote: > > On Thu, Mar 05, 2015 at 09:22:55AM +0100, Pablo Rauzy wrote: > >> My first question is about sections. > >> I would like to be able to add a title and a little description for each > >> section, just like I can with the cgit.desc configuration for each the > >> git repos. > >> > >> Example : http://clandest.in/sensi > >> Here I would like the title to be "clandest.in / sensi" rather than just > >> "clandest.in", and I would like the description to be "SEN Security > >> Inspector" rather than the root description. > > > > Are you currently using "section-from-path"? If you use the > > "repo.section" configuration option then you can name the sections > > however you want, but this is not possible if you are generating the > > sections automatically. > > Indeed I am using section-from-path, but the name of the sections are > just fine. > > What I was looking for is the possibility to for instance make cgit > using a file called "description" in the directory that it makes a > section as description of that section. I don't think this has ever been supported. I hadn't realised that http://clandest.in/sensi wasn't the root of the repository. CGit doesn't generate any links to the section pages so I'm not sure much thought has gone into the formatting of those pages. > > If you're combining CGit with Gitolite you may be able to avoid listing > > repositories twice by using CGit's "enable-git-config" option to > > configure the "repo.section" variable (I'm not sure if you can set a > > config variable on a group of repositories in Gitolite, but I think you > > should be able to). > > I'm not using Gitolite. > > >> My second question is about repository. > >> I would like to add title and a link to a project home page somewhere > >> else than on the logo. > >> > >> Example : http://clandest.in/sensi/finja > >> Here I would like the title to be "clandest.in / sensi / finja" rather > >> than "index : finja", and I would like to add a tab "homepage" after > >> "diff" which would link to http://pablo.rauzy.name/sensi/finja.html in > >> this example. > >> > >> > >> Is what I'm looking for already possible? If yes, how? If not, I think > >> it would be a nice addition. > > > > I don't think this is currently possible. Note that the word "index" is > > actually a link to the list of repositories. > > Yes I noticed that, but I find it less nice than having the root-title > for the link. > > > For the "homepage" link, have you considered simply adding a link to the > > repository's readme (on the about tab)? I thought there was a way to > > make the "about" tab the default instead of the "summary" tab, but I > > can't find it when I go looking so I must be wrong about that. > > That is exactly what I did for now. Maybe it is enough. I'll see with > the time how much I like it this way :). > > FWIW, here is the filter I wrote to make link clickable in plaintext > READMEs: http://paste.fulltxt.net/LKdVjbHaY (it is quick and dirty, it > simply considers that anything between < and > and starting with "http" > is a link). Note that there is a collection of scripts in the "filters" directory that will handle Markdown, ReStructuredText and a variety of other formats. From Jason at zx2c4.com Thu Mar 5 11:46:55 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 5 Mar 2015 11:46:55 +0100 Subject: [PATCH] Simplify commit and tag parsing In-Reply-To: <1425384007-18681-1-git-send-email-cgit@cryptocrack.de> References: <1425384007-18681-1-git-send-email-cgit@cryptocrack.de> Message-ID: This commit breaks ui-tag. The first few lines of tag messages are cut off. From john at keeping.me.uk Thu Mar 5 11:52:43 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 10:52:43 +0000 Subject: [PATCH] Simplify commit and tag parsing In-Reply-To: References: <1425384007-18681-1-git-send-email-cgit@cryptocrack.de> Message-ID: <20150305105243.GC1369@serenity.lan> On Thu, Mar 05, 2015 at 11:46:55AM +0100, Jason A. Donenfeld wrote: > This commit breaks ui-tag. The first few lines of tag messages are cut off. It looks like parse_user() consumes the trailing LF on the user line, so next_header_line() ends up skipping the blank line at the end of the header. I suspect the right answer is to stop parse_user() eating the LF since all of the call sites go through next_header_line() after this patch. From r at uzy.me Thu Mar 5 12:16:40 2015 From: r at uzy.me (Pablo Rauzy) Date: Thu, 05 Mar 2015 12:16:40 +0100 Subject: Description for section and link for repos In-Reply-To: <20150305095739.GB1369@serenity.lan> References: <87mw3rvoo0.fsf@uzy.me> <20150305093030.GA1369@serenity.lan> <87lhjbvkky.fsf@uzy.me> <20150305095739.GB1369@serenity.lan> Message-ID: <87ioefvhc3.fsf@uzy.me> On 2015-03-05, John Keeping wrote: > On Thu, Mar 05, 2015 at 10:51:09AM +0100, Pablo Rauzy wrote: >> What I was looking for is the possibility to for instance make cgit >> using a file called "description" in the directory that it makes a >> section as description of that section. > > I don't think this has ever been supported. > > CGit doesn't generate any links to the section pages so I'm not sure > much thought has gone into the formatting of those pages. That's what I infered. But I'd like to have both the link and the formatting. I'll think about it when I have time to. >> FWIW, here is the filter I wrote to make link clickable in plaintext >> READMEs: http://paste.fulltxt.net/LKdVjbHaY (it is quick and dirty, it >> simply considers that anything between < and > and starting with "http" >> is a link). > > Note that there is a collection of scripts in the "filters" directory > that will handle Markdown, ReStructuredText and a variety of other > formats. Yes I saw that, thanks. But I prefer to keep things simple (I only have plaintext and html readme) and fast as cgit already is :). Thanks, -- Pablo Rauzy. http://pablo.rauzy.name/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From cgit at cryptocrack.de Thu Mar 5 12:58:11 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Thu, 5 Mar 2015 12:58:11 +0100 Subject: [PATCH 1/2] Remove leading newline characters from tag messages Message-ID: <1425556692-1022-1-git-send-email-cgit@cryptocrack.de> Fixes a regression introduced in commit 936295c (Simplify commit and tag parsing, 2015-03-03). Signed-off-by: Lukas Fleischer --- parsing.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/parsing.c b/parsing.c index 0db181b..dcaf2b3 100644 --- a/parsing.c +++ b/parsing.c @@ -216,6 +216,9 @@ struct taginfo *cgit_parse_tag(struct tag *tag) } } + while (p && *p == '\n') + p++; + if (p && *p) ret->msg = xstrdup(p); -- 2.3.1 From cgit at cryptocrack.de Thu Mar 5 12:58:12 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Thu, 5 Mar 2015 12:58:12 +0100 Subject: [PATCH 2/2] Drop return value from parse_user() In-Reply-To: <1425556692-1022-1-git-send-email-cgit@cryptocrack.de> References: <1425556692-1022-1-git-send-email-cgit@cryptocrack.de> Message-ID: <1425556692-1022-2-git-send-email-cgit@cryptocrack.de> In commit 936295c (Simplify commit and tag parsing, 2015-03-03), the commit and tag parsing code was refactored. This broke tag messages in ui-tag since the line after the tagger header was erroneously skipped. Rework parse_user() and skip the line manually outside parse_user(). Signed-off-by: Lukas Fleischer --- parsing.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/parsing.c b/parsing.c index dcaf2b3..f903c7c 100644 --- a/parsing.c +++ b/parsing.c @@ -69,13 +69,12 @@ static char *substr(const char *head, const char *tail) return buf; } -static const char *parse_user(const char *t, char **name, char **email, unsigned long *date) +static void parse_user(const char *t, char **name, char **email, unsigned long *date) { - const char *line_end = strchrnul(t, '\n'); struct ident_split ident; unsigned email_len; - if (!split_ident_line(&ident, t, line_end - t)) { + if (!split_ident_line(&ident, t, strchrnul(t, '\n') - t)) { *name = substr(ident.name_begin, ident.name_end); email_len = ident.mail_end - ident.mail_begin; @@ -85,11 +84,6 @@ static const char *parse_user(const char *t, char **name, char **email, unsigned if (ident.date_begin) *date = strtoul(ident.date_begin, NULL, 10); } - - if (*line_end) - return line_end + 1; - else - return line_end; } #ifdef NO_ICONV @@ -152,13 +146,15 @@ struct commitinfo *cgit_parse_commit(struct commit *commit) p += sha1hex_len + 1; if (p && skip_prefix(p, "author ", &p)) { - p = parse_user(p, &ret->author, &ret->author_email, + parse_user(p, &ret->author, &ret->author_email, &ret->author_date); + p = next_header_line(p); } if (p && skip_prefix(p, "committer ", &p)) { - p = parse_user(p, &ret->committer, &ret->committer_email, + parse_user(p, &ret->committer, &ret->committer_email, &ret->committer_date); + p = next_header_line(p); } if (p && skip_prefix(p, "encoding ", &p)) { @@ -211,7 +207,7 @@ struct taginfo *cgit_parse_tag(struct tag *tag) for (p = data; !end_of_header(p); p = next_header_line(p)) { if (skip_prefix(p, "tagger ", &p)) { - p = parse_user(p, &ret->tagger, &ret->tagger_email, + parse_user(p, &ret->tagger, &ret->tagger_email, &ret->tagger_date); } } -- 2.3.1 From Jason at zx2c4.com Thu Mar 5 16:06:36 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 5 Mar 2015 16:06:36 +0100 Subject: [ANNOUNCE] CGIT v0.11.1 Released Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi folks, CGit 0.11.1 is now available, with some important bug fixes, as well as tweaks done for the new gitweb.gentoo.org site. == CGit on the Web == * homepage: http://git.zx2c4.com/cgit/about/ * git repository: http://git.zx2c4.com/cgit/ * git clone: git://git.zx2c4.com/cgit * mailing list: cgit at lists.zx2c4.com * mailing list subscribe: http://lists.zx2c4.com/mailman/listinfo/cgit == ChangeLog v0.11.1 == 10 files changed, 127 insertions(+), 113 deletions(-) Changes: * Uses internally Git 2.3.1 * Optimized commit and tag parsing * The sample simple-authentication.lua has been hardened Bug fixes: * When clicking on an owner in the index, use the right query string for searching * When filtering in the index, make the sorting links point to the same filtered page of results * Also, the same as above, but with pagination links * F_SETLK is now used to avoid creating stale lock files == Downloading == * http://git.zx2c4.com/cgit/snapshot/cgit-0.11.1.tar.xz fce62bd440891f796fa0e471dfd539ca0e5521b4 (sha1) * For verification git tag v0.11.1 is signed with my public key: zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc Thanks to everyone who contributed to this release! Jason Donenfeld -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU+HDWAAoJEEn8cBKl3gOuE0IP/2ZRQ9EIjF+1b3QsL8XrTq0R sWC74YN82uvzp/eOQei5O2FeglTYCKn4QWMG4f/zjQK9jhhBRGOkcIaYHaDWCTQw Q39NELHeDCwl8aTjSa9FPYv4l9+w5j2M1eajcOvKg8PlvyyQJuJ7ryZNsT+W6O7T zLmaQc4HKixv/pw7qbjg2AcwCchMxfLtyqZL/zIOtFXhTKLsVMywsfj8DMb7f5cD L6ImDRoufVX5CKeJcZi0kEXHD8WQRnw3+jvKfCom3nClc/17mqusjWJ/q2WvsGQP 3uQ8ZnX1effjlFZD3mSwR+05yZeRVdDAuFkneQqhqUlYexadIP+jf6MT7c1n6s3U NIBPMiGEM8ORSmWHYjnn0+8BZk31sWb8cml7g8zUnafH5OknGw7y58LqvwEBnzfk ua8NK2cmBcGjZzpexWxwJxdZlOdYV4VKETEeZQc3s9LRyqkmxQkxNBq9ArhT+hjU emlioZihVlxm2MJkbgynPgCSJJT7ipkNHgbE/odh1oxwjKhXtJ4HUdH00WqUxvEx 9nSavmzoYSf4Ir7lrgH5YXO4MEqCZKl07NUplcbhyxA1IeHKty3JhtOJfNKzSgVx mV4zTUR2eRMESGmpIXUDM6hqhiZW8ZRSFm1lk3CizGhMkAR4/Qd3KBrDl6HhN87X mJAbYOfJzvUYBx0AeBJx =aQkx -----END PGP SIGNATURE----- From glogow at fbihome.de Thu Mar 5 18:15:04 2015 From: glogow at fbihome.de (Jan-Marek Glogowski) Date: Thu, 5 Mar 2015 18:15:04 +0100 Subject: [PATCH] Support .git/category files Message-ID: <1425575704-15107-1-git-send-email-glogow@fbihome.de> Gitweb reads .git/category to set a repository section for grouping. This handles the file in the same way a .git/description file is handled. The file section takes precedence over the ctx.cfg.section_from_path setting. --- cgit.c | 2 +- cgit.h | 1 + scan-tree.c | 20 +++++++++++++++++++- shared.c | 1 + 4 files changed, 22 insertions(+), 2 deletions(-) diff --git a/cgit.c b/cgit.c index 0ad8171..239f709 100644 --- a/cgit.c +++ b/cgit.c @@ -377,7 +377,7 @@ static void prepare_context(void) ctx.cfg.root_desc = "a fast webinterface for the git dscm"; ctx.cfg.scan_hidden_path = 0; ctx.cfg.script_name = CGIT_SCRIPT_NAME; - ctx.cfg.section = ""; + ctx.cfg.section = cgit_default_repo_section; ctx.cfg.repository_sort = "name"; ctx.cfg.section_sort = 1; ctx.cfg.summary_branches = 10; diff --git a/cgit.h b/cgit.h index 16f8092..ea9aef9 100644 --- a/cgit.h +++ b/cgit.h @@ -318,6 +318,7 @@ extern struct cgit_context ctx; extern const struct cgit_snapshot_format cgit_snapshot_formats[]; extern char *cgit_default_repo_desc; +extern char *cgit_default_repo_section; extern struct cgit_repo *cgit_add_repo(const char *url); extern struct cgit_repo *cgit_get_repoinfo(const char *url); extern void cgit_repo_config_cb(const char *name, const char *value); diff --git a/scan-tree.c b/scan-tree.c index e900ad9..c7ba509 100644 --- a/scan-tree.c +++ b/scan-tree.c @@ -149,7 +149,25 @@ static void add_repo(const char *base, struct strbuf *path, repo_config_fn fn) strbuf_setlen(path, pathlen); } - if (ctx.cfg.section_from_path) { + if (repo->section == cgit_default_repo_section || !repo->section) { + strbuf_addstr(path, "category"); + if (!stat(path->buf, &st) && + !readfile(path->buf, &repo->section, &size)) { + // trim category, as gitweb does + while (size > 0 && isspace((unsigned char)repo->section[size - 1])) + size--; + if (size == 0) { + free(repo->section); + repo->section = cgit_default_repo_section; + } + else + repo->section[size] = '\0'; + } + strbuf_setlen(path, pathlen); + } + + if (ctx.cfg.section_from_path + && (repo->section == cgit_default_repo_section || !repo->section)) { n = ctx.cfg.section_from_path; if (n > 0) { slash = rel.buf - 1; diff --git a/shared.c b/shared.c index ae17d78..4b21da2 100644 --- a/shared.c +++ b/shared.c @@ -34,6 +34,7 @@ int chk_non_negative(int result, char *msg) } char *cgit_default_repo_desc = "[no description]"; +char *cgit_default_repo_section = ""; struct cgit_repo *cgit_add_repo(const char *url) { struct cgit_repo *ret; -- 1.9.1 From john at keeping.me.uk Thu Mar 5 18:38:25 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 17:38:25 +0000 Subject: [PATCH] Support .git/category files In-Reply-To: <1425575704-15107-1-git-send-email-glogow@fbihome.de> References: <1425575704-15107-1-git-send-email-glogow@fbihome.de> Message-ID: <20150305173825.GD1369@serenity.lan> On Thu, Mar 05, 2015 at 06:15:04PM +0100, Jan-Marek Glogowski wrote: > Gitweb reads .git/category to set a repository section for > grouping. This handles the file in the same way a .git/description > file is handled. > > The file section takes precedence over the ctx.cfg.section_from_path > setting. What's the advantage of this over using "enable-git-config=1" and "cgit.section" (we even support "gitweb.section" as an alias)? > --- > cgit.c | 2 +- > cgit.h | 1 + > scan-tree.c | 20 +++++++++++++++++++- > shared.c | 1 + > 4 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/cgit.c b/cgit.c > index 0ad8171..239f709 100644 > --- a/cgit.c > +++ b/cgit.c > @@ -377,7 +377,7 @@ static void prepare_context(void) > ctx.cfg.root_desc = "a fast webinterface for the git dscm"; > ctx.cfg.scan_hidden_path = 0; > ctx.cfg.script_name = CGIT_SCRIPT_NAME; > - ctx.cfg.section = ""; > + ctx.cfg.section = cgit_default_repo_section; > ctx.cfg.repository_sort = "name"; > ctx.cfg.section_sort = 1; > ctx.cfg.summary_branches = 10; > diff --git a/cgit.h b/cgit.h > index 16f8092..ea9aef9 100644 > --- a/cgit.h > +++ b/cgit.h > @@ -318,6 +318,7 @@ extern struct cgit_context ctx; > extern const struct cgit_snapshot_format cgit_snapshot_formats[]; > > extern char *cgit_default_repo_desc; > +extern char *cgit_default_repo_section; > extern struct cgit_repo *cgit_add_repo(const char *url); > extern struct cgit_repo *cgit_get_repoinfo(const char *url); > extern void cgit_repo_config_cb(const char *name, const char *value); > diff --git a/scan-tree.c b/scan-tree.c > index e900ad9..c7ba509 100644 > --- a/scan-tree.c > +++ b/scan-tree.c > @@ -149,7 +149,25 @@ static void add_repo(const char *base, struct strbuf *path, repo_config_fn fn) > strbuf_setlen(path, pathlen); > } > > - if (ctx.cfg.section_from_path) { > + if (repo->section == cgit_default_repo_section || !repo->section) { > + strbuf_addstr(path, "category"); > + if (!stat(path->buf, &st) && > + !readfile(path->buf, &repo->section, &size)) { > + // trim category, as gitweb does > + while (size > 0 && isspace((unsigned char)repo->section[size - 1])) > + size--; > + if (size == 0) { > + free(repo->section); > + repo->section = cgit_default_repo_section; > + } > + else > + repo->section[size] = '\0'; > + } > + strbuf_setlen(path, pathlen); > + } > + > + if (ctx.cfg.section_from_path > + && (repo->section == cgit_default_repo_section || !repo->section)) { > n = ctx.cfg.section_from_path; > if (n > 0) { > slash = rel.buf - 1; > diff --git a/shared.c b/shared.c > index ae17d78..4b21da2 100644 > --- a/shared.c > +++ b/shared.c > @@ -34,6 +34,7 @@ int chk_non_negative(int result, char *msg) > } > > char *cgit_default_repo_desc = "[no description]"; > +char *cgit_default_repo_section = ""; > struct cgit_repo *cgit_add_repo(const char *url) > { > struct cgit_repo *ret; > -- > 1.9.1 > > _______________________________________________ > CGit mailing list > CGit at lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/cgit From cgit at cryptocrack.de Thu Mar 5 18:41:30 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Thu, 05 Mar 2015 18:41:30 +0100 Subject: [PATCH] Support .git/category files In-Reply-To: <1425575704-15107-1-git-send-email-glogow@fbihome.de> References: <1425575704-15107-1-git-send-email-glogow@fbihome.de> Message-ID: <20150305174130.12633.85067@s-8d3a28b1.on.site.uni-stuttgart.de> On Thu, 05 Mar 2015 at 18:15:04, Jan-Marek Glogowski wrote: > Gitweb reads .git/category to set a repository section for > grouping. This handles the file in the same way a .git/description > file is handled. > > The file section takes precedence over the ctx.cfg.section_from_path > setting. > --- > cgit.c | 2 +- > cgit.h | 1 + > scan-tree.c | 20 +++++++++++++++++++- > shared.c | 1 + > 4 files changed, 22 insertions(+), 2 deletions(-) > [...] There already are at least two ways to achieve the same thing (using the Git configuration variables gitweb.category or cgit.section and repository-specific cgitrc files). Do we really need another alternative? Is this just for GitWeb compatibility or does this have any advantages over the existing options? From glogow at fbihome.de Thu Mar 5 18:50:47 2015 From: glogow at fbihome.de (Jan-Marek Glogowski) Date: Thu, 05 Mar 2015 18:50:47 +0100 Subject: [PATCH] Support .git/category files In-Reply-To: <20150305173825.GD1369@serenity.lan> References: <1425575704-15107-1-git-send-email-glogow@fbihome.de> <20150305173825.GD1369@serenity.lan> Message-ID: <54F89777.4090508@fbihome.de> Am 05.03.2015 um 18:38 schrieb John Keeping: > What's the advantage of this over using "enable-git-config=1" and > "cgit.section" (we even support "gitweb.section" as an alias)? Well - I have 100+ repositories, which already have the "category" file. There is no "advantage" over any other method. Am 05.03.2015 um 18:41 schrieb Lukas Fleischer:> > There already are at least two ways to achieve the same thing (using > the Git configuration variables gitweb.category or cgit.section and > repository-specific cgitrc files). Do we really need another > alternative? Is this just for GitWeb compatibility or does this have > any advantages over the existing options? Yes - it's "just" GitWeb compatibility, like - I guess - the "description" file support just the few lines before my path. JMG From john at keeping.me.uk Thu Mar 5 19:01:39 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 18:01:39 +0000 Subject: [PATCH] Support .git/category files In-Reply-To: <54F89777.4090508@fbihome.de> References: <1425575704-15107-1-git-send-email-glogow@fbihome.de> <20150305173825.GD1369@serenity.lan> <54F89777.4090508@fbihome.de> Message-ID: <20150305180139.GE1369@serenity.lan> On Thu, Mar 05, 2015 at 06:50:47PM +0100, Jan-Marek Glogowski wrote: > Am 05.03.2015 um 18:38 schrieb John Keeping: > > What's the advantage of this over using "enable-git-config=1" and > > "cgit.section" (we even support "gitweb.section" as an alias)? > > Well - I have 100+ repositories, which already have the "category" file. > There is no "advantage" over any other method. > > Am 05.03.2015 um 18:41 schrieb Lukas Fleischer:> > > There already are at least two ways to achieve the same thing (using > > the Git configuration variables gitweb.category or cgit.section and > > repository-specific cgitrc files). Do we really need another > > alternative? Is this just for GitWeb compatibility or does this have > > any advantages over the existing options? > > Yes - it's "just" GitWeb compatibility, like - I guess - the > "description" file support just the few lines before my path. The "description" file is a bit different though - it's in the default repository template that ships with Git and is used by the sample hooks that ship there. I'm not sure "category" is similar enough, particularly when you can do: for repo in $repositories do git -C "$repo" config gitweb.category "$(cat "$repo"/category)" && rm -f "$repo"/category done and still have a configuration that works with both Gitweb and CGit. From terrence.j.dunnigan at boeing.com Thu Mar 5 19:19:31 2015 From: terrence.j.dunnigan at boeing.com (Dunnigan, Terrence J) Date: Thu, 5 Mar 2015 18:19:31 +0000 Subject: Support for submodules in tree view? Message-ID: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> Hi all, We are using cgit 0.10.1. Some of our repos have submodules, and when I look at a tree view I see the name of the submodule with its current hash, e.g. m--------- Utilities @ 350bc94 The submodule names are all hyperlinks, but the actual link is just a "#". So clicking on it doesn't do anything. Is this the correct behavior? Or something on my system improperly configured to support submodules? Thanks, Terry -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at keeping.me.uk Thu Mar 5 19:25:53 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 18:25:53 +0000 Subject: Support for submodules in tree view? In-Reply-To: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> References: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> Message-ID: <20150305182553.GF1369@serenity.lan> On Thu, Mar 05, 2015 at 06:19:31PM +0000, Dunnigan, Terrence J wrote: > We are using cgit 0.10.1. Some of our repos have submodules, and when > I look at a tree view I see the name of the submodule with its current > hash, e.g. > > m--------- Utilities @ 350bc94 > > The submodule names are all hyperlinks, but the actual link is just a > "#". So clicking on it doesn't do anything. > > Is this the correct behavior? Or something on my system improperly > configured to support submodules? You probably need to set the "module-link" configuration variable in your cgitrc file. Since it's possible for submodules to link to a different server, there isn't really much CGit can do in the general case. Note that there's also "repo.module-link." in case your submodule paths don't match up to their URLs, although I'm quite surprised we don't support a filter to map submodule URLs to links - something to go on the TODO list perhaps... From cgit at cryptocrack.de Thu Mar 5 19:31:01 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Thu, 05 Mar 2015 19:31:01 +0100 Subject: Support for submodules in tree view? In-Reply-To: <20150305182553.GF1369@serenity.lan> References: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> <20150305182553.GF1369@serenity.lan> Message-ID: <20150305183101.14312.67532@s-8d3a28b1.on.site.uni-stuttgart.de> On Thu, 05 Mar 2015 at 19:25:53, John Keeping wrote: > On Thu, Mar 05, 2015 at 06:19:31PM +0000, Dunnigan, Terrence J wrote: > > We are using cgit 0.10.1. Some of our repos have submodules, and when > > I look at a tree view I see the name of the submodule with its current > > hash, e.g. > > > > m--------- Utilities @ 350bc94 > > > > The submodule names are all hyperlinks, but the actual link is just a > > "#". So clicking on it doesn't do anything. > > > > Is this the correct behavior? Or something on my system improperly > > configured to support submodules? > > You probably need to set the "module-link" configuration variable in > your cgitrc file. > > Since it's possible for submodules to link to a different server, there > isn't really much CGit can do in the general case. Note that there's > also "repo.module-link." in case your submodule paths don't match > up to their URLs, although I'm quite surprised we don't support a filter > to map submodule URLs to links - something to go on the TODO list > perhaps... What do you think about hiding the "#" link, though? I don't think it is a good idea to pretend there is a link when there isn't... -- >8 -- diff --git a/ui-shared.c b/ui-shared.c index ff03cb2..0eeab6f 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -555,25 +555,27 @@ void cgit_submodule_link(const char *class, char *path, const char *rev) item = lookup_path(list, path); } } - html("module_link, dir, rev); + if (item || ctx.repo->module_link) { + html("module_link, dir, rev); + } + html("'>"); + html_txt(path); + html(""); } else { - html("#"); + html_txt(path); } - html("'>"); - html_txt(path); - html(""); html_txtf(" @ %.7s", rev); if (item && tail) path[len - 1] = tail; From john at keeping.me.uk Thu Mar 5 19:34:20 2015 From: john at keeping.me.uk (John Keeping) Date: Thu, 5 Mar 2015 18:34:20 +0000 Subject: Support for submodules in tree view? In-Reply-To: <20150305183101.14312.67532@s-8d3a28b1.on.site.uni-stuttgart.de> References: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> <20150305182553.GF1369@serenity.lan> <20150305183101.14312.67532@s-8d3a28b1.on.site.uni-stuttgart.de> Message-ID: <20150305183420.GG1369@serenity.lan> On Thu, Mar 05, 2015 at 07:31:01PM +0100, Lukas Fleischer wrote: > On Thu, 05 Mar 2015 at 19:25:53, John Keeping wrote: > > On Thu, Mar 05, 2015 at 06:19:31PM +0000, Dunnigan, Terrence J wrote: > > > We are using cgit 0.10.1. Some of our repos have submodules, and when > > > I look at a tree view I see the name of the submodule with its current > > > hash, e.g. > > > > > > m--------- Utilities @ 350bc94 > > > > > > The submodule names are all hyperlinks, but the actual link is just a > > > "#". So clicking on it doesn't do anything. > > > > > > Is this the correct behavior? Or something on my system improperly > > > configured to support submodules? > > > > You probably need to set the "module-link" configuration variable in > > your cgitrc file. > > > > Since it's possible for submodules to link to a different server, there > > isn't really much CGit can do in the general case. Note that there's > > also "repo.module-link." in case your submodule paths don't match > > up to their URLs, although I'm quite surprised we don't support a filter > > to map submodule URLs to links - something to go on the TODO list > > perhaps... > > What do you think about hiding the "#" link, though? I don't think it is > a good idea to pretend there is a link when there isn't... Good idea. My one concern would be that it hinders discovery of the module-link feature, but I think that is outweighed by the fact that it is perfectly reasonable for someone to only want to link some of the submodules in their system to a web interface. > -- >8 -- > diff --git a/ui-shared.c b/ui-shared.c > index ff03cb2..0eeab6f 100644 > --- a/ui-shared.c > +++ b/ui-shared.c > @@ -555,25 +555,27 @@ void cgit_submodule_link(const char *class, char *path, const char *rev) > item = lookup_path(list, path); > } > } > - html(" - if (class) > - htmlf("class='%s' ", class); > - html("href='"); > - if (item) { > - html_attrf(item->util, rev); > - } else if (ctx.repo->module_link) { > - dir = strrchr(path, '/'); > - if (dir) > - dir++; > - else > - dir = path; > - html_attrf(ctx.repo->module_link, dir, rev); > + if (item || ctx.repo->module_link) { > + html(" + if (class) > + htmlf("class='%s' ", class); > + html("href='"); > + if (item) { > + html_attrf(item->util, rev); > + } else { > + dir = strrchr(path, '/'); > + if (dir) > + dir++; > + else > + dir = path; > + html_attrf(ctx.repo->module_link, dir, rev); > + } > + html("'>"); > + html_txt(path); > + html(""); > } else { > - html("#"); > + html_txt(path); > } > - html("'>"); > - html_txt(path); > - html(""); > html_txtf(" @ %.7s", rev); > if (item && tail) > path[len - 1] = tail; > _______________________________________________ > CGit mailing list > CGit at lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/cgit From cgit at cryptocrack.de Thu Mar 5 20:41:45 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Thu, 5 Mar 2015 20:41:45 +0100 Subject: [PATCH] Remove no-op link from submodule entries Message-ID: <1425584505-16593-1-git-send-email-cgit@cryptocrack.de> Instead of linking to the current page ("href='#'"), do not add a link to a submodule entry at all if the module-link setting is not used. Signed-off-by: Lukas Fleischer --- cgit.css | 2 +- ui-shared.c | 41 ++++++++++++++++++++++++----------------- 2 files changed, 25 insertions(+), 18 deletions(-) diff --git a/cgit.css b/cgit.css index 6888cde..82c755c 100644 --- a/cgit.css +++ b/cgit.css @@ -254,7 +254,7 @@ div#cgit div.error { margin: 1em 2em; } -div#cgit a.ls-blob, div#cgit a.ls-dir, div#cgit a.ls-mod { +div#cgit a.ls-blob, div#cgit a.ls-dir, div#cgit .ls-mod { font-family: monospace; } diff --git a/ui-shared.c b/ui-shared.c index ff03cb2..c8c1ae0 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -555,25 +555,32 @@ void cgit_submodule_link(const char *class, char *path, const char *rev) item = lookup_path(list, path); } } - html("module_link, dir, rev); + if (item || ctx.repo->module_link) { + html("module_link, dir, rev); + } + html("'>"); + html_txt(path); + html(""); } else { - html("#"); + html(""); + html_txt(path); + html(""); } - html("'>"); - html_txt(path); - html(""); html_txtf(" @ %.7s", rev); if (item && tail) path[len - 1] = tail; -- 2.3.1 From terrence.j.dunnigan at boeing.com Fri Mar 6 06:58:21 2015 From: terrence.j.dunnigan at boeing.com (Dunnigan, Terrence J) Date: Fri, 6 Mar 2015 05:58:21 +0000 Subject: Support for submodules in tree view? In-Reply-To: <20150305182553.GF1369@serenity.lan> References: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> <20150305182553.GF1369@serenity.lan> Message-ID: <9AD8B655B5126D4FAE1397203CDDBF2D12CCA2@XCH-PHX-213.sw.nos.boeing.com> Thank you. Do you have an example or two of values for module-link? I didn't see an example on the sample config file at http://git.zx2c4.com/cgit/tree/cgitrc.5.txt If both module-link and repo.module-link are present, would repo.module-link override the global module-link? Terry -----Original Message----- From: John Keeping [mailto:john at keeping.me.uk] Sent: Thursday, March 05, 2015 12:26 PM To: Dunnigan, Terrence J Cc: cgit at lists.zx2c4.com Subject: Re: Support for submodules in tree view? On Thu, Mar 05, 2015 at 06:19:31PM +0000, Dunnigan, Terrence J wrote: > We are using cgit 0.10.1. Some of our repos have submodules, and when > I look at a tree view I see the name of the submodule with its current > hash, e.g. > > m--------- Utilities @ 350bc94 > > The submodule names are all hyperlinks, but the actual link is just a > "#". So clicking on it doesn't do anything. > > Is this the correct behavior? Or something on my system improperly > configured to support submodules? You probably need to set the "module-link" configuration variable in your cgitrc file. Since it's possible for submodules to link to a different server, there isn't really much CGit can do in the general case. Note that there's also "repo.module-link." in case your submodule paths don't match up to their URLs, although I'm quite surprised we don't support a filter to map submodule URLs to links - something to go on the TODO list perhaps... From john at keeping.me.uk Fri Mar 6 10:09:30 2015 From: john at keeping.me.uk (John Keeping) Date: Fri, 6 Mar 2015 09:09:30 +0000 Subject: Support for submodules in tree view? In-Reply-To: <9AD8B655B5126D4FAE1397203CDDBF2D12CCA2@XCH-PHX-213.sw.nos.boeing.com> References: <9AD8B655B5126D4FAE1397203CDDBF2D1274B5@XCH-PHX-205.sw.nos.boeing.com> <20150305182553.GF1369@serenity.lan> <9AD8B655B5126D4FAE1397203CDDBF2D12CCA2@XCH-PHX-213.sw.nos.boeing.com> Message-ID: <20150306090930.GH1369@serenity.lan> On Fri, Mar 06, 2015 at 05:58:21AM +0000, Dunnigan, Terrence J wrote: > Do you have an example or two of values for module-link? I didn't see > an example on the sample config file at > http://git.zx2c4.com/cgit/tree/cgitrc.5.txt git-instacgit[0] autogenerates submodule links as: module-link=/cgit/submodule/%s/commit?id=%s then adds the submodule repositories as something like: repo.url=submodule/git repo.path=/home/john/src/cgit/.git/modules/git where the "repo.url" value is simply "submodule/${sm_path}". Because this "module-link" only gets the path at which the submodule is installed in the parent repository, I think this is hard to use in a generic way. > If both module-link and repo.module-link are present, would > repo.module-link override the global module-link? Yes. [0] https://github.com/johnkeeping/git-instacgit > -----Original Message----- > From: John Keeping [mailto:john at keeping.me.uk] > Sent: Thursday, March 05, 2015 12:26 PM > To: Dunnigan, Terrence J > Cc: cgit at lists.zx2c4.com > Subject: Re: Support for submodules in tree view? > > On Thu, Mar 05, 2015 at 06:19:31PM +0000, Dunnigan, Terrence J wrote: > > We are using cgit 0.10.1. Some of our repos have submodules, and when > > I look at a tree view I see the name of the submodule with its current > > hash, e.g. > > > > m--------- Utilities @ 350bc94 > > > > The submodule names are all hyperlinks, but the actual link is just a > > "#". So clicking on it doesn't do anything. > > > > Is this the correct behavior? Or something on my system improperly > > configured to support submodules? > > You probably need to set the "module-link" configuration variable in your cgitrc file. > > Since it's possible for submodules to link to a different server, there isn't really much CGit can do in the general case. Note that there's also "repo.module-link." in case your submodule paths don't match up to their URLs, although I'm quite surprised we don't support a filter to map submodule URLs to links - something to go on the TODO list perhaps... > _______________________________________________ > CGit mailing list > CGit at lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/cgit From list at eworm.de Sat Mar 7 12:44:39 2015 From: list at eworm.de (Christian Hesse) Date: Sat, 7 Mar 2015 12:44:39 +0100 Subject: [PATCH 1/1] git: update to v2.3.2 Message-ID: <1425728679-6549-1-git-send-email-list@eworm.de> From: Christian Hesse Update to git version v2.3.2, no changes required. Signed-off-by: Christian Hesse --- Makefile | 2 +- git | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index a6935c0..ed329e8 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ htmldir = $(docdir) pdfdir = $(docdir) mandir = $(prefix)/share/man SHA1_HEADER = -GIT_VER = 2.3.1 +GIT_VER = 2.3.2 GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.gz INSTALL = install COPYTREE = cp -r diff --git a/git b/git index 8004647..1165ae6 160000 --- a/git +++ b/git @@ -1 +1 @@ -Subproject commit 8004647a217c26f708bce2aa26ed94a4a0ed575d +Subproject commit 1165ae6f3d42e0eb0ddfc2d4e6dfa8bd0b88eb60 -- 2.3.1 From Jason at zx2c4.com Sat Mar 7 12:45:30 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sat, 7 Mar 2015 12:45:30 +0100 Subject: [PATCH 1/1] git: update to v2.3.2 In-Reply-To: <1425728679-6549-1-git-send-email-list@eworm.de> References: <1425728679-6549-1-git-send-email-list@eworm.de> Message-ID: Merged, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at keeping.me.uk Sat Mar 7 15:46:41 2015 From: john at keeping.me.uk (John Keeping) Date: Sat, 7 Mar 2015 14:46:41 +0000 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading Message-ID: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> This requires that we save the downloaded file explicitly rather than piping it straight to tar, but that is advisable anyway since it allows us to check the exit status of curl and make sure that we have downloaded the file successfully. Also add a test to make sure we don't forget to update the file when updating our Git version in the future. Signed-off-by: John Keeping --- Makefile | 8 ++++++-- git.sha256sum | 1 + tests/t0001-validate-git-versions.sh | 11 +++++++++++ 3 files changed, 18 insertions(+), 2 deletions(-) create mode 100644 git.sha256sum diff --git a/Makefile b/Makefile index ed329e8..807879f 100644 --- a/Makefile +++ b/Makefile @@ -15,7 +15,8 @@ pdfdir = $(docdir) mandir = $(prefix)/share/man SHA1_HEADER = GIT_VER = 2.3.2 -GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.gz +GIT_FILE = git-$(GIT_VER).tar.gz +GIT_URL = https://www.kernel.org/pub/software/scm/git/$(GIT_FILE) INSTALL = install COPYTREE = cp -r MAN5_TXT = $(wildcard *.5.txt) @@ -146,7 +147,10 @@ clean-doc: $(RM) cgitrc.5 cgitrc.5.html cgitrc.5.pdf cgitrc.5.xml cgitrc.5.fo get-git: - curl -L $(GIT_URL) | tar -xzf - && rm -rf git && mv git-$(GIT_VER) git + curl -L $(GIT_URL) --output $(GIT_FILE) && \ + sha256sum --check git.sha256sum && \ + tar -xzf $(GIT_FILE) && \ + rm -rf git && mv git-$(GIT_VER) git tags: $(QUIET_TAGS)find . -name '*.[ch]' | xargs ctags diff --git a/git.sha256sum b/git.sha256sum new file mode 100644 index 0000000..1214d3d --- /dev/null +++ b/git.sha256sum @@ -0,0 +1 @@ +a35aea3a0f63f4cc3dd38fa32127e97273f335a14ea2586b649eb759ecf675a3 git-2.3.2.tar.gz diff --git a/tests/t0001-validate-git-versions.sh b/tests/t0001-validate-git-versions.sh index a65b35e..3325c77 100755 --- a/tests/t0001-validate-git-versions.sh +++ b/tests/t0001-validate-git-versions.sh @@ -9,6 +9,12 @@ test_expect_success 'extract Git version from Makefile' ' s/^GIT_VER[ ]*=[ ]*// p }" ../../Makefile >makefile_version + GIT_VER=$(cat makefile_version) + sed -n -e "/^GIT_FILE[ ]*=/ { + s/^GIT_FILE[ ]*=[ ]*// + s/\$(GIT_VER)/$GIT_VER/ + p + }" ../../Makefile >makefile_file ' # Note that Git's GIT-VERSION-GEN script applies "s/-/./g" to the version @@ -38,4 +44,9 @@ test_expect_success 'test submodule version matches Makefile' ' fi ' +test_expect_success 'git.sha256sum version matches Makefile' ' + sed -e "s/[0-9a-z]* *//" ../../git.sha256sum >sha256sum_file + test_cmp sha256sum_file makefile_file +' + test_done -- 2.3.1.308.g754cd77 From cgit at cryptocrack.de Sat Mar 7 16:59:26 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Sat, 07 Mar 2015 16:59:26 +0100 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> Message-ID: <20150307155926.6430.47439@typhoon> On Sat, 07 Mar 2015 at 15:46:41, John Keeping wrote: > This requires that we save the downloaded file explicitly rather than > piping it straight to tar, but that is advisable anyway since it allows > us to check the exit status of curl and make sure that we have > downloaded the file successfully. > > Also add a test to make sure we don't forget to update the file when > updating our Git version in the future. > > Signed-off-by: John Keeping > --- > Makefile | 8 ++++++-- > git.sha256sum | 1 + > tests/t0001-validate-git-versions.sh | 11 +++++++++++ > 3 files changed, 18 insertions(+), 2 deletions(-) > create mode 100644 git.sha256sum > [...] I like the idea, however, sha256sum is not available on all platforms. This breaks `make get-git` under OpenBSD, for example (OpenBSD has a utility called sha256 with a different command line interface). Maybe we can make the check optional, though? On a related note, can we download a signature and use `gpg --verify` instead (should probably be optional as well, to avoid a dependency on GnuPG)? From john at keeping.me.uk Sat Mar 7 18:02:59 2015 From: john at keeping.me.uk (John Keeping) Date: Sat, 7 Mar 2015 17:02:59 +0000 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307155926.6430.47439@typhoon> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> Message-ID: <20150307170259.GI1369@serenity.lan> On Sat, Mar 07, 2015 at 04:59:26PM +0100, Lukas Fleischer wrote: > On Sat, 07 Mar 2015 at 15:46:41, John Keeping wrote: > > This requires that we save the downloaded file explicitly rather than > > piping it straight to tar, but that is advisable anyway since it allows > > us to check the exit status of curl and make sure that we have > > downloaded the file successfully. > > > > Also add a test to make sure we don't forget to update the file when > > updating our Git version in the future. > > > > Signed-off-by: John Keeping > > --- > > Makefile | 8 ++++++-- > > git.sha256sum | 1 + > > tests/t0001-validate-git-versions.sh | 11 +++++++++++ > > 3 files changed, 18 insertions(+), 2 deletions(-) > > create mode 100644 git.sha256sum > > [...] > > I like the idea, however, sha256sum is not available on all platforms. > This breaks `make get-git` under OpenBSD, for example (OpenBSD has a > utility called sha256 with a different command line interface). Maybe we > can make the check optional, though? I'm not sure what benefit it has if it's optional. Will anyone check? Maybe we could do something like: if type sha256sum >/dev/null 2>&1 then sha256sum --check git.sha256sum $(GIT_FILE) else echo >&2 'WARNING: sha256sum not found so we cannot verify' echo >&2 'WARNING: the integrity of the Git archive!' fi > On a related note, can we download a signature and use `gpg --verify` > instead (should probably be optional as well, to avoid a dependency on > GnuPG)? I thought about that, but we'd have to embed a key with CGit for it to work reliably and how do we choose what key to use (given that individual Git archives are not signed - the list of SHA256 checksums is)? From cgit at cryptocrack.de Sat Mar 7 18:49:32 2015 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Sat, 07 Mar 2015 18:49:32 +0100 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307170259.GI1369@serenity.lan> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> Message-ID: <20150307174932.8657.41364@typhoon> On Sat, 07 Mar 2015 at 18:02:59, John Keeping wrote: > [...] > I'm not sure what benefit it has if it's optional. Will anyone check? > > Maybe we could do something like: > > if type sha256sum >/dev/null 2>&1 > then > sha256sum --check git.sha256sum $(GIT_FILE) > else > echo >&2 'WARNING: sha256sum not found so we cannot verify' > echo >&2 'WARNING: the integrity of the Git archive!' > fi > That is exactly what I meant by suggesting to make it optional. Sorry for being vague... > > On a related note, can we download a signature and use `gpg --verify` > > instead (should probably be optional as well, to avoid a dependency on > > GnuPG)? > > I thought about that, but we'd have to embed a key with CGit for it to > work reliably and how do we choose what key to use (given that > individual Git archives are not signed - the list of SHA256 checksums > is)? > Huh? This works fine for me: $ gpg --recv-keys 96AFE6CB gpg: key 713660A7: public key "Junio C Hamano " imported gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Total number processed: 1 gpg: imported: 1 $ curl -OO https://www.kernel.org/pub/software/scm/git/git-2.3.2.tar.{xz,sign} % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3529k 100 3529k 0 0 1133k 0 0:00:03 0:00:03 --:--:-- 1133k 100 543 100 543 0 0 3404 0 --:--:-- --:--:-- --:--:-- 3404 $ unxz git-2.3.2.tar.xz $ gpg --verify git-2.3.2.tar.sign gpg: assuming signed data in 'git-2.3.2.tar' gpg: Signature made Sat 07 Mar 2015 12:10:41 AM CET using RSA key ID 96AFE6CB gpg: Good signature from "Junio C Hamano " [unknown] gpg: aka "Junio C Hamano " [unknown] gpg: aka "Junio C Hamano " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 96E0 7AF2 5771 9559 80DA D100 20D0 4E5A 7136 60A7 Subkey fingerprint: E1F0 36B1 FEE7 221F C778 ECEF B0B5 E886 96AF E6CB From john at keeping.me.uk Sat Mar 7 19:20:03 2015 From: john at keeping.me.uk (John Keeping) Date: Sat, 7 Mar 2015 18:20:03 +0000 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307174932.8657.41364@typhoon> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> Message-ID: <20150307182002.GJ1369@serenity.lan> On Sat, Mar 07, 2015 at 06:49:32PM +0100, Lukas Fleischer wrote: > On Sat, 07 Mar 2015 at 18:02:59, John Keeping wrote: > > [...] > > I'm not sure what benefit it has if it's optional. Will anyone check? > > > > Maybe we could do something like: > > > > if type sha256sum >/dev/null 2>&1 > > then > > sha256sum --check git.sha256sum $(GIT_FILE) > > else > > echo >&2 'WARNING: sha256sum not found so we cannot verify' > > echo >&2 'WARNING: the integrity of the Git archive!' > > fi > > > > That is exactly what I meant by suggesting to make it optional. Sorry > for being vague... > > > > On a related note, can we download a signature and use `gpg --verify` > > > instead (should probably be optional as well, to avoid a dependency on > > > GnuPG)? > > > > I thought about that, but we'd have to embed a key with CGit for it to > > work reliably and how do we choose what key to use (given that > > individual Git archives are not signed - the list of SHA256 checksums > > is)? > > > > Huh? This works fine for me: > > $ gpg --recv-keys 96AFE6CB > gpg: key 713660A7: public key "Junio C Hamano " imported > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: Total number processed: 1 > gpg: imported: 1 > $ curl -OO https://www.kernel.org/pub/software/scm/git/git-2.3.2.tar.{xz,sign} > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 3529k 100 3529k 0 0 1133k 0 0:00:03 0:00:03 --:--:-- 1133k > 100 543 100 543 0 0 3404 0 --:--:-- --:--:-- --:--:-- 3404 > $ unxz git-2.3.2.tar.xz Oh, I tried this earlier but completely missed the fact that the signature was on the bare tar file not one of the compressed versions. I still think we can't rely on `gpg --recv-keys` though, we would have to distribute the key with CGit and possible also do something to avoid importing it into the user's keyring by default. I think a hash is more appropriate for the situation we're in - we are assuming that the user is happy that the CGit distribution they have is trustworthy but we must verify that the Git distribution we download is also correct. > $ gpg --verify git-2.3.2.tar.sign > gpg: assuming signed data in 'git-2.3.2.tar' > gpg: Signature made Sat 07 Mar 2015 12:10:41 AM CET using RSA key ID 96AFE6CB > gpg: Good signature from "Junio C Hamano " [unknown] > gpg: aka "Junio C Hamano " [unknown] > gpg: aka "Junio C Hamano " [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: 96E0 7AF2 5771 9559 80DA D100 20D0 4E5A 7136 60A7 > Subkey fingerprint: E1F0 36B1 FEE7 221F C778 ECEF B0B5 E886 96AF E6CB From tmz at pobox.com Sun Mar 8 00:35:10 2015 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 7 Mar 2015 18:35:10 -0500 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307182002.GJ1369@serenity.lan> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> Message-ID: <20150307233510.GU3567@zaya.teonanacatl.net> John Keeping wrote: > I still think we can't rely on `gpg --recv-keys` though, we would > have to distribute the key with CGit and possible also do something > to avoid importing it into the user's keyring by default. If the check was to be run from a cgit clone, the key Junio uses to sign git tarballs could be included as a blob, similarly to how it's done in git.git. (See the junio-gpg-pub tag in git.git for anyone unfamiliar with this already. The key can be extracted via: git cat-file blob junio-gpg-pub I've always thought that was a neat use of git, but certainly not a common one. I can't manage to make github display this tagged blob, which is also amusing. The cgit-hosted kernel.org repo displays it easily though: http://git.kernel.org/cgit/git/git.git/tag/?id=junio-gpg-pub) This method does nothing for users who have downloaded a cgit tarball, of course, which I expect is more likely to be the use case you're targeting. > I think a hash is more appropriate for the situation we're in - we > are assuming that the user is happy that the CGit distribution they > have is trustworthy but we must verify that the Git distribution we > download is also correct. I don't think this is unreasonable at all. Trust has to start somewhere. For users that want to go to the source, they can always download git directly (or just the detached PGP signature) and verify the tarball. When I updated cgit packages in Fedora and EPEL, this is what I always did. I don't know if the current maintainers follow that process still, but hopefully they do. ;) But while we're on the subject, are there PGP signatures available for the cgit tarballs themselves? I know the git tags are signed, but I don't think I've seen detached signatures for the tarballs. In this case, how does a user become "happy that the CGit distribution they have is trustworthy"? The cgit tarball download isn't available via https either, which might be a reasonable answer in the absence of a detached git signature. Without a signature on the tarball or some other method to verify the cgit tarball, the sha256 of the git tarball included in the cgit Makefile is more or less only useful as a basic download integrity check (in which case sha256 is mild overkill). None of this is to say that this patch isn't a step in the right direction. It certainly helps to display a nicer error message if a user receives a corrupted git tarball. It's just important that users don't confuse this with providing any real authentication of the git tarball. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Life is the art of drawing without an eraser. -- John Gardner From john at keeping.me.uk Sun Mar 8 11:45:21 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 10:45:21 +0000 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307233510.GU3567@zaya.teonanacatl.net> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> <20150307233510.GU3567@zaya.teonanacatl.net> Message-ID: <20150308104520.GK1369@serenity.lan> On Sat, Mar 07, 2015 at 06:35:10PM -0500, Todd Zullinger wrote: > John Keeping wrote: > > I still think we can't rely on `gpg --recv-keys` though, we would > > have to distribute the key with CGit and possible also do something > > to avoid importing it into the user's keyring by default. > > If the check was to be run from a cgit clone, the key Junio uses to > sign git tarballs could be included as a blob, similarly to how it's > done in git.git. My assumption is that if people have cloned CGit then they will probably clone Git as well, at which point they check out an explicit SHA-1. > (See the junio-gpg-pub tag in git.git for anyone unfamiliar with this > already. The key can be extracted via: > > git cat-file blob junio-gpg-pub > > I've always thought that was a neat use of git, but certainly not a > common one. I can't manage to make github display this tagged blob, > which is also amusing. > > The cgit-hosted kernel.org repo displays it easily though: > > http://git.kernel.org/cgit/git/git.git/tag/?id=junio-gpg-pub) > > This method does nothing for users who have downloaded a cgit tarball, > of course, which I expect is more likely to be the use case you're > targeting. Precisely. > > I think a hash is more appropriate for the situation we're in - we > > are assuming that the user is happy that the CGit distribution they > > have is trustworthy but we must verify that the Git distribution we > > download is also correct. > > I don't think this is unreasonable at all. Trust has to start > somewhere. For users that want to go to the source, they can always > download git directly (or just the detached PGP signature) and verify > the tarball. When I updated cgit packages in Fedora and EPEL, this is > what I always did. I don't know if the current maintainers follow > that process still, but hopefully they do. ;) > > But while we're on the subject, are there PGP signatures available for > the cgit tarballs themselves? I know the git tags are signed, but I > don't think I've seen detached signatures for the tarballs. In this > case, how does a user become "happy that the CGit distribution they > have is trustworthy"? The cgit tarball download isn't available via > https either, which might be a reasonable answer in the absence of a > detached git signature. > > Without a signature on the tarball or some other method to verify the > cgit tarball, the sha256 of the git tarball included in the cgit > Makefile is more or less only useful as a basic download integrity > check (in which case sha256 is mild overkill). > > None of this is to say that this patch isn't a step in the right > direction. It certainly helps to display a nicer error message if a > user receives a corrupted git tarball. It's just important that users > don't confuse this with providing any real authentication of the git > tarball. I'm not sure this is true. Providing that the CGit tarball is trusted, then I think this does provide sufficient authentication of the Git tarball. If the CGit tarball isn't trusted, then all bets are off anyway. From john at keeping.me.uk Sun Mar 8 17:32:14 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:14 +0000 Subject: [PATCH 00/13] Fixes for problems detected by Sparse Message-ID: Sparse[0] detects several potential problems in CGit, which are all fixed by this set of patches. Most of these are style issues that are correct either way (using integer zero as a NULL pointer), but I think there is value in keeping the build clean of Sparse warnings. [0] https://sparse.wiki.kernel.org/index.php/Main_Page John Keeping (13): Makefile: add a target to run CGit through sparse Avoid non-ANSI function declarations Avoid signed bitfields scan-tree: make some variables 'static' shared: make some variables 'static' ui-log: make some variables 'static' ui-repolist: make sortcolumn definitions 'static const' ui-shared: make cgit_doctype 'static' ui-stats: make cgit_period definitions 'static const' ui-shared: avoid initializing static variable to zero ui-shared: don't use an integer as a NULL pointer cache: don't use an integer as a NULL pointer html: avoid using a plain integer as a NULL pointer Makefile | 3 +++ cache.c | 2 +- cgit.c | 2 +- cgit.mk | 9 ++++++++- filter.c | 2 +- html.c | 54 ++++++++++++++++++++++++++++++++---------------------- scan-tree.c | 4 ++-- shared.c | 4 ++-- ui-blob.c | 4 ++-- ui-diff.c | 4 ++-- ui-log.c | 2 +- ui-refs.c | 4 ++-- ui-repolist.c | 10 +++++----- ui-shared.c | 18 +++++++++--------- ui-ssdiff.c | 16 ++++++++-------- ui-stats.c | 14 +++++++------- ui-stats.h | 2 +- ui-summary.c | 2 +- ui-tree.c | 4 ++-- 19 files changed, 90 insertions(+), 70 deletions(-) -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:15 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:15 +0000 Subject: [PATCH 01/13] Makefile: add a target to run CGit through sparse In-Reply-To: References: Message-ID: <19cda3e7a1fd7d174be055e25aab8afc3198182b.1425832128.git.john@keeping.me.uk> Signed-off-by: John Keeping --- Makefile | 3 +++ cgit.mk | 9 ++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ed329e8..42ed230 100644 --- a/Makefile +++ b/Makefile @@ -68,6 +68,9 @@ all:: cgit cgit: $(QUIET_SUBDIR0)git $(QUIET_SUBDIR1) -f ../cgit.mk ../cgit $(EXTRA_GIT_TARGETS) NO_CURL=1 +sparse: + $(QUIET_SUBDIR0)git $(QUIET_SUBDIR1) -f ../cgit.mk NO_CURL=1 cgit-sparse + test: @$(MAKE) --no-print-directory cgit EXTRA_GIT_TARGETS=all $(QUIET_SUBDIR0)tests $(QUIET_SUBDIR1) all diff --git a/cgit.mk b/cgit.mk index 5048b09..1b50307 100644 --- a/cgit.mk +++ b/cgit.mk @@ -96,7 +96,7 @@ CGIT_OBJS := $(addprefix $(CGIT_PREFIX),$(CGIT_OBJ_NAMES)) # Only cgit.c reference CGIT_VERSION so we only rebuild its objects when the # version changes. -CGIT_VERSION_OBJS := $(addprefix $(CGIT_PREFIX),cgit.o) +CGIT_VERSION_OBJS := $(addprefix $(CGIT_PREFIX),cgit.o cgit.sp) $(CGIT_VERSION_OBJS): $(CGIT_PREFIX)VERSION $(CGIT_VERSION_OBJS): EXTRA_CPPFLAGS = \ -DCGIT_VERSION='"$(CGIT_VERSION)"' @@ -129,3 +129,10 @@ $(CGIT_OBJS): %.o: %.c GIT-CFLAGS $(CGIT_PREFIX)CGIT-CFLAGS $(missing_dep_dirs) $(CGIT_PREFIX)cgit: $(CGIT_OBJS) GIT-LDFLAGS $(GITLIBS) @echo 1>&1 " * $(LUA_MESSAGE)" $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS) $(CGIT_LIBS) + +CGIT_SP_OBJS := $(patsubst %.o,%.sp,$(CGIT_OBJS)) + +$(CGIT_SP_OBJS): %.sp: %.c GIT-CFLAGS $(CGIT_PREFIX)CGIT-CFLAGS FORCE + $(QUIET_SP)cgcc -no-compile $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $(CGIT_CFLAGS) $(SPARSE_FLAGS) $< + +cgit-sparse: $(CGIT_SP_OBJS) -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:16 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:16 +0000 Subject: [PATCH 02/13] Avoid non-ANSI function declarations In-Reply-To: References: Message-ID: <27256c18b255f71ce19c3f1b3aea4f057f4a714b.1425832128.git.john@keeping.me.uk> Sparse says things like: warning: non-ANSI function declaration of function 'calc_ttl' Signed-off-by: John Keeping --- cgit.c | 2 +- filter.c | 2 +- ui-diff.c | 2 +- ui-refs.c | 4 ++-- ui-repolist.c | 6 +++--- ui-shared.c | 12 ++++++------ ui-ssdiff.c | 16 ++++++++-------- ui-summary.c | 2 +- ui-tree.c | 4 ++-- 9 files changed, 25 insertions(+), 25 deletions(-) diff --git a/cgit.c b/cgit.c index 0ad8171..c16ed8c 100644 --- a/cgit.c +++ b/cgit.c @@ -1013,7 +1013,7 @@ static void cgit_parse_args(int argc, const char **argv) } } -static int calc_ttl() +static int calc_ttl(void) { if (!ctx.repo) return ctx.cfg.cache_root_ttl; diff --git a/filter.c b/filter.c index 9f433db..ebf4937 100644 --- a/filter.c +++ b/filter.c @@ -72,7 +72,7 @@ static inline void hook_write(struct cgit_filter *filter, ssize_t (*new_write)(s filter_write = new_write; } -static inline void unhook_write() +static inline void unhook_write(void) { assert(filter_write != NULL); assert(current_write_filter != NULL); diff --git a/ui-diff.c b/ui-diff.c index 5b6df1f..8eff178 100644 --- a/ui-diff.c +++ b/ui-diff.c @@ -311,7 +311,7 @@ static void filepair_cb(struct diff_filepair *pair) cgit_ssdiff_footer(); } -void cgit_print_diff_ctrls() +void cgit_print_diff_ctrls(void) { int i, curr; diff --git a/ui-refs.c b/ui-refs.c index ac8a6d4..d3d71dd 100644 --- a/ui-refs.c +++ b/ui-refs.c @@ -82,7 +82,7 @@ static int print_branch(struct refinfo *ref) return 0; } -static void print_tag_header() +static void print_tag_header(void) { html("Tag" "Download" @@ -234,7 +234,7 @@ void cgit_print_tags(int maxcount) cgit_free_reflist_inner(&list); } -void cgit_print_refs() +void cgit_print_refs(void) { html(""); diff --git a/ui-repolist.c b/ui-repolist.c index e945f67..a6d0321 100644 --- a/ui-repolist.c +++ b/ui-repolist.c @@ -117,7 +117,7 @@ static void print_sort_header(const char *title, const char *sort) htmlf("'>%s", title); } -static void print_header() +static void print_header(void) { html(""); print_sort_header("Name", "name"); @@ -247,7 +247,7 @@ static int sort_repolist(char *field) } -void cgit_print_repolist() +void cgit_print_repolist(void) { int i, columns = 3, hits = 0, header = 0; char *last_section = NULL; @@ -344,7 +344,7 @@ void cgit_print_repolist() cgit_print_docend(); } -void cgit_print_site_readme() +void cgit_print_site_readme(void) { if (!ctx.cfg.root_readme) return; diff --git a/ui-shared.c b/ui-shared.c index ff03cb2..6d3cfa9 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -46,7 +46,7 @@ void cgit_vprint_error(const char *fmt, va_list ap) html("\n"); } -const char *cgit_httpscheme() +const char *cgit_httpscheme(void) { if (ctx.env.https && !strcmp(ctx.env.https, "on")) return "https://"; @@ -54,7 +54,7 @@ const char *cgit_httpscheme() return "http://"; } -const char *cgit_hosturl() +const char *cgit_hosturl(void) { if (ctx.env.http_host) return ctx.env.http_host; @@ -65,14 +65,14 @@ const char *cgit_hosturl() return fmtalloc("%s:%s", ctx.env.server_name, ctx.env.server_port); } -const char *cgit_currenturl() +const char *cgit_currenturl(void) { if (!ctx.qry.url) return cgit_rooturl(); return ctx.qry.url; } -const char *cgit_rooturl() +const char *cgit_rooturl(void) { if (ctx.cfg.virtual_root) return ctx.cfg.virtual_root; @@ -80,7 +80,7 @@ const char *cgit_rooturl() return ctx.cfg.script_name; } -const char *cgit_loginurl() +const char *cgit_loginurl(void) { static const char *login_url = 0; if (!login_url) @@ -735,7 +735,7 @@ void cgit_print_docstart(void) html_include(ctx.cfg.header); } -void cgit_print_docend() +void cgit_print_docend(void) { html("\n"); if (ctx.cfg.embedded) { diff --git a/ui-ssdiff.c b/ui-ssdiff.c index 08cf513..2146c71 100644 --- a/ui-ssdiff.c +++ b/ui-ssdiff.c @@ -18,7 +18,7 @@ struct deferred_lines { static struct deferred_lines *deferred_old, *deferred_old_last; static struct deferred_lines *deferred_new, *deferred_new_last; -static void create_or_reset_lcs_table() +static void create_or_reset_lcs_table(void) { int i; @@ -276,7 +276,7 @@ static void print_ssdiff_line(char *class, free(old_line); } -static void print_deferred_old_lines() +static void print_deferred_old_lines(void) { struct deferred_lines *iter_old, *tmp; iter_old = deferred_old; @@ -289,7 +289,7 @@ static void print_deferred_old_lines() } } -static void print_deferred_new_lines() +static void print_deferred_new_lines(void) { struct deferred_lines *iter_new, *tmp; iter_new = deferred_new; @@ -302,7 +302,7 @@ static void print_deferred_new_lines() } } -static void print_deferred_changed_lines() +static void print_deferred_changed_lines(void) { struct deferred_lines *iter_old, *iter_new, *tmp; int n_old_lines = calc_deferred_lines(deferred_old); @@ -337,7 +337,7 @@ static void print_deferred_changed_lines() } } -void cgit_ssdiff_print_deferred_lines() +void cgit_ssdiff_print_deferred_lines(void) { if (!deferred_old && !deferred_new) return; @@ -388,7 +388,7 @@ void cgit_ssdiff_line_cb(char *line, int len) line[len - 1] = c; } -void cgit_ssdiff_header_begin() +void cgit_ssdiff_header_begin(void) { current_old_line = -1; current_new_line = -1; @@ -396,12 +396,12 @@ void cgit_ssdiff_header_begin() html(""); } -void cgit_ssdiff_footer() +void cgit_ssdiff_footer(void) { if (deferred_old || deferred_new) cgit_ssdiff_print_deferred_lines(); diff --git a/ui-summary.c b/ui-summary.c index fa5ba04..b0af073 100644 --- a/ui-summary.c +++ b/ui-summary.c @@ -40,7 +40,7 @@ static void print_url(const char *url) html("\n"); } -void cgit_print_summary() +void cgit_print_summary(void) { int columns = 3; diff --git a/ui-tree.c b/ui-tree.c index 4ab0137..bbc468e 100644 --- a/ui-tree.c +++ b/ui-tree.c @@ -180,7 +180,7 @@ static int ls_item(const unsigned char *sha1, struct strbuf *base, return 0; } -static void ls_head() +static void ls_head(void) { html("

"); } -void cgit_ssdiff_header_end() +void cgit_ssdiff_header_end(void) { html("

\n"); html(""); @@ -191,7 +191,7 @@ static void ls_head() html("\n"); } -static void ls_tail() +static void ls_tail(void) { html("

\n"); } -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:17 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:17 +0000 Subject: [PATCH 03/13] Avoid signed bitfields In-Reply-To: References: Message-ID: Bitfields are only defined for unsigned types. Detected by sparse. Signed-off-by: John Keeping --- ui-blob.c | 4 ++-- ui-diff.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ui-blob.c b/ui-blob.c index a025bca..388a017 100644 --- a/ui-blob.c +++ b/ui-blob.c @@ -14,8 +14,8 @@ struct walk_tree_context { const char *match_path; unsigned char *matched_sha1; - int found_path:1; - int file_only:1; + unsigned int found_path:1; + unsigned int file_only:1; }; static int walk_tree(const unsigned char *sha1, struct strbuf *base, diff --git a/ui-diff.c b/ui-diff.c index 8eff178..1cf2ce0 100644 --- a/ui-diff.c +++ b/ui-diff.c @@ -31,7 +31,7 @@ static struct fileinfo { unsigned int removed; unsigned long old_size; unsigned long new_size; - int binary:1; + unsigned int binary:1; } *items; static int use_ssdiff = 0; -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:18 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:18 +0000 Subject: [PATCH 04/13] scan-tree: make some variables 'static' In-Reply-To: References: Message-ID: These are not used outside this file and are not declared. Signed-off-by: John Keeping --- scan-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scan-tree.c b/scan-tree.c index e900ad9..8e3cf52 100644 --- a/scan-tree.c +++ b/scan-tree.c @@ -45,8 +45,8 @@ out: return result; } -struct cgit_repo *repo; -repo_config_fn config_fn; +static struct cgit_repo *repo; +static repo_config_fn config_fn; static void repo_config(const char *name, const char *value) { -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:19 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:19 +0000 Subject: [PATCH 05/13] shared: make some variables 'static' In-Reply-To: References: Message-ID: <083fd28819d06ed810ab54d9ac1523ab23c09212.1425832129.git.john@keeping.me.uk> These are not used outside this file and are not declared. Signed-off-by: John Keeping --- shared.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/shared.c b/shared.c index ae17d78..a99173b 100644 --- a/shared.c +++ b/shared.c @@ -284,8 +284,8 @@ static int load_mmfile(mmfile_t *file, const unsigned char *sha1) * ripped from git and modified to use globals instead of * a special callback-struct. */ -char *diffbuf = NULL; -int buflen = 0; +static char *diffbuf = NULL; +static int buflen = 0; static int filediff_cb(void *priv, mmbuffer_t *mb, int nbuf) { -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:20 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:20 +0000 Subject: [PATCH 06/13] ui-log: make some variables 'static' In-Reply-To: References: Message-ID: <96dcabdd30fa091b23d321c7a058535f0e9bf939.1425832129.git.john@keeping.me.uk> These are not used outside this file and are not declared. Signed-off-by: John Keeping --- ui-log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui-log.c b/ui-log.c index 1b60591..32b4c47 100644 --- a/ui-log.c +++ b/ui-log.c @@ -12,7 +12,7 @@ #include "ui-shared.h" #include "argv-array.h" -int files, add_lines, rem_lines; +static int files, add_lines, rem_lines; /* * The list of available column colors in the commit graph. -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:21 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:21 +0000 Subject: [PATCH 07/13] ui-repolist: make sortcolumn definitions 'static const' In-Reply-To: References: Message-ID: <6cb41c3c9d6ad0a397b7acfc13a160a5635e4c09.1425832129.git.john@keeping.me.uk> These are not used outside this file and are not declared; they are also never modified. Signed-off-by: John Keeping --- ui-repolist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ui-repolist.c b/ui-repolist.c index a6d0321..2453a7f 100644 --- a/ui-repolist.c +++ b/ui-repolist.c @@ -223,7 +223,7 @@ struct sortcolumn { int (*fn)(const void *a, const void *b); }; -struct sortcolumn sortcolumn[] = { +static const struct sortcolumn sortcolumn[] = { {"section", sort_section}, {"name", sort_name}, {"desc", sort_desc}, @@ -234,7 +234,7 @@ struct sortcolumn sortcolumn[] = { static int sort_repolist(char *field) { - struct sortcolumn *column; + const struct sortcolumn *column; for (column = &sortcolumn[0]; column->name; column++) { if (strcmp(field, column->name)) -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:22 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:22 +0000 Subject: [PATCH 08/13] ui-shared: make cgit_doctype 'static' In-Reply-To: References: Message-ID: This is not used outside this file and is not declared. Signed-off-by: John Keeping --- ui-shared.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui-shared.c b/ui-shared.c index 6d3cfa9..d4c4bb9 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -11,7 +11,7 @@ #include "cmd.h" #include "html.h" -const char cgit_doctype[] = +static const char cgit_doctype[] = "\n"; -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:23 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:23 +0000 Subject: [PATCH 09/13] ui-stats: make cgit_period definitions 'static const' In-Reply-To: References: Message-ID: <480f57e7c083dfb0bbeb1a8dc8ad415021422c0a.1425832129.git.john@keeping.me.uk> These definitions should not be modified (and never are) so we can move them to .rodata. Signed-off-by: John Keeping --- ui-stats.c | 14 +++++++------- ui-stats.h | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/ui-stats.c b/ui-stats.c index a264f6a..9cd8247 100644 --- a/ui-stats.c +++ b/ui-stats.c @@ -125,7 +125,7 @@ static char *pretty_year(struct tm *tm) return fmt("%d", tm->tm_year + 1900); } -struct cgit_period periods[] = { +static const struct cgit_period periods[] = { {'w', "week", 12, 4, trunc_week, dec_week, inc_week, pretty_week}, {'m', "month", 12, 4, trunc_month, dec_month, inc_month, pretty_month}, {'q', "quarter", 12, 4, trunc_quarter, dec_quarter, inc_quarter, pretty_quarter}, @@ -136,7 +136,7 @@ struct cgit_period periods[] = { * and update the period pointer to the correcsponding struct. * If no matching code is found, return 0. */ -int cgit_find_stats_period(const char *expr, struct cgit_period **period) +int cgit_find_stats_period(const char *expr, const struct cgit_period **period) { int i; char code = '\0'; @@ -165,7 +165,7 @@ const char *cgit_find_stats_periodname(int idx) } static void add_commit(struct string_list *authors, struct commit *commit, - struct cgit_period *period) + const struct cgit_period *period) { struct commitinfo *info; struct string_list_item *author, *item; @@ -209,7 +209,7 @@ static int cmp_total_commits(const void *a1, const void *a2) /* Walk the commit DAG and collect number of commits per author per * timeperiod into a nested string_list collection. */ -static struct string_list collect_stats(struct cgit_period *period) +static struct string_list collect_stats(const struct cgit_period *period) { struct string_list authors; struct rev_info rev; @@ -256,7 +256,7 @@ static void print_combined_authorrow(struct string_list *authors, int from, const char *leftclass, const char *centerclass, const char *rightclass, - struct cgit_period *period) + const struct cgit_period *period) { struct string_list_item *author; struct authorstat *authorstat; @@ -295,7 +295,7 @@ static void print_combined_authorrow(struct string_list *authors, int from, } static void print_authors(struct string_list *authors, int top, - struct cgit_period *period) + const struct cgit_period *period) { struct string_list_item *author; struct authorstat *authorstat; @@ -363,7 +363,7 @@ static void print_authors(struct string_list *authors, int top, void cgit_show_stats(void) { struct string_list authors; - struct cgit_period *period; + const struct cgit_period *period; int top, i; const char *code = "w"; diff --git a/ui-stats.h b/ui-stats.h index 341ab13..0e61b03 100644 --- a/ui-stats.h +++ b/ui-stats.h @@ -20,7 +20,7 @@ struct cgit_period { char *(*pretty)(struct tm *tm); }; -extern int cgit_find_stats_period(const char *expr, struct cgit_period **period); +extern int cgit_find_stats_period(const char *expr, const struct cgit_period **period); extern const char *cgit_find_stats_periodname(int idx); extern void cgit_show_stats(void); -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:24 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:24 +0000 Subject: [PATCH 10/13] ui-shared: avoid initializing static variable to zero In-Reply-To: References: Message-ID: Sparse complains that we are using a plain integer as a NULL pointer here, but in fact we do not have to specify a value for this variable at all since it has static storage duration and thus will be initialized to NULL by the compiler. Signed-off-by: John Keeping --- ui-shared.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui-shared.c b/ui-shared.c index d4c4bb9..1e3c131 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -82,7 +82,7 @@ const char *cgit_rooturl(void) const char *cgit_loginurl(void) { - static const char *login_url = 0; + static const char *login_url; if (!login_url) login_url = fmtalloc("%s?p=login", cgit_rooturl()); return login_url; -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:25 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:25 +0000 Subject: [PATCH 11/13] ui-shared: don't use an integer as a NULL pointer In-Reply-To: References: Message-ID: <153432d4e67543a678322cfbd1674efda572e62e.1425832129.git.john@keeping.me.uk> Signed-off-by: John Keeping --- ui-shared.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui-shared.c b/ui-shared.c index 1e3c131..7bcb8d3 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -119,7 +119,7 @@ char *cgit_fileurl(const char *reponame, const char *pagename, char *cgit_pageurl(const char *reponame, const char *pagename, const char *query) { - return cgit_fileurl(reponame, pagename, 0, query); + return cgit_fileurl(reponame, pagename, NULL, query); } const char *cgit_repobasename(const char *reponame) -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:26 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:26 +0000 Subject: [PATCH 12/13] cache: don't use an integer as a NULL pointer In-Reply-To: References: Message-ID: <5c1bd4ea2fdfe80ff1cb5aa5780783c8514a5a8d.1425832129.git.john@keeping.me.uk> Signed-off-by: John Keeping --- cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cache.c b/cache.c index 900b161..cd99812 100644 --- a/cache.c +++ b/cache.c @@ -411,7 +411,7 @@ int cache_ls(const char *path) DIR *dir; struct dirent *ent; int err = 0; - struct cache_slot slot = { 0 }; + struct cache_slot slot = { NULL }; struct strbuf fullname = STRBUF_INIT; size_t prefixlen; -- 2.3.1.308.g754cd77 From john at keeping.me.uk Sun Mar 8 17:32:27 2015 From: john at keeping.me.uk (John Keeping) Date: Sun, 8 Mar 2015 16:32:27 +0000 Subject: [PATCH 13/13] html: avoid using a plain integer as a NULL pointer In-Reply-To: References: Message-ID: <07d8e371cb2f13540e8b21f87e44917899bebce1.1425832129.git.john@keeping.me.uk> Sparse complains about this table because we use the integer zero as the NULL pointer. Use this as an opportunity to reformat the table so that it always contains 8 elements per row, making it easier to see which values are being set and which are not. Signed-off-by: John Keeping --- html.c | 54 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/html.c b/html.c index f0ee2d6..155cde5 100644 --- a/html.c +++ b/html.c @@ -17,28 +17,38 @@ /* Percent-encoding of each character, except: a-zA-Z0-9!$()*,./:;@- */ static const char* url_escape_table[256] = { - "%00", "%01", "%02", "%03", "%04", "%05", "%06", "%07", "%08", "%09", - "%0a", "%0b", "%0c", "%0d", "%0e", "%0f", "%10", "%11", "%12", "%13", - "%14", "%15", "%16", "%17", "%18", "%19", "%1a", "%1b", "%1c", "%1d", - "%1e", "%1f", "%20", 0, "%22", "%23", 0, "%25", "%26", "%27", 0, 0, 0, - "%2b", 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, "%3c", "%3d", - "%3e", "%3f", 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, - 0, 0, 0, 0, 0, 0, 0, 0, 0, "%5c", 0, "%5e", 0, "%60", 0, 0, 0, 0, 0, - 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, "%7b", - "%7c", "%7d", 0, "%7f", "%80", "%81", "%82", "%83", "%84", "%85", - "%86", "%87", "%88", "%89", "%8a", "%8b", "%8c", "%8d", "%8e", "%8f", - "%90", "%91", "%92", "%93", "%94", "%95", "%96", "%97", "%98", "%99", - "%9a", "%9b", "%9c", "%9d", "%9e", "%9f", "%a0", "%a1", "%a2", "%a3", - "%a4", "%a5", "%a6", "%a7", "%a8", "%a9", "%aa", "%ab", "%ac", "%ad", - "%ae", "%af", "%b0", "%b1", "%b2", "%b3", "%b4", "%b5", "%b6", "%b7", - "%b8", "%b9", "%ba", "%bb", "%bc", "%bd", "%be", "%bf", "%c0", "%c1", - "%c2", "%c3", "%c4", "%c5", "%c6", "%c7", "%c8", "%c9", "%ca", "%cb", - "%cc", "%cd", "%ce", "%cf", "%d0", "%d1", "%d2", "%d3", "%d4", "%d5", - "%d6", "%d7", "%d8", "%d9", "%da", "%db", "%dc", "%dd", "%de", "%df", - "%e0", "%e1", "%e2", "%e3", "%e4", "%e5", "%e6", "%e7", "%e8", "%e9", - "%ea", "%eb", "%ec", "%ed", "%ee", "%ef", "%f0", "%f1", "%f2", "%f3", - "%f4", "%f5", "%f6", "%f7", "%f8", "%f9", "%fa", "%fb", "%fc", "%fd", - "%fe", "%ff" + "%00", "%01", "%02", "%03", "%04", "%05", "%06", "%07", + "%08", "%09", "%0a", "%0b", "%0c", "%0d", "%0e", "%0f", + "%10", "%11", "%12", "%13", "%14", "%15", "%16", "%17", + "%18", "%19", "%1a", "%1b", "%1c", "%1d", "%1e", "%1f", + "%20", NULL, "%22", "%23", NULL, "%25", "%26", "%27", + NULL, NULL, NULL, "%2b", NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, "%3c", "%3d", "%3e", "%3f", + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, "%5c", NULL, "%5e", NULL, + "%60", NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, "%7b", "%7c", "%7d", NULL, "%7f", + "%80", "%81", "%82", "%83", "%84", "%85", "%86", "%87", + "%88", "%89", "%8a", "%8b", "%8c", "%8d", "%8e", "%8f", + "%90", "%91", "%92", "%93", "%94", "%95", "%96", "%97", + "%98", "%99", "%9a", "%9b", "%9c", "%9d", "%9e", "%9f", + "%a0", "%a1", "%a2", "%a3", "%a4", "%a5", "%a6", "%a7", + "%a8", "%a9", "%aa", "%ab", "%ac", "%ad", "%ae", "%af", + "%b0", "%b1", "%b2", "%b3", "%b4", "%b5", "%b6", "%b7", + "%b8", "%b9", "%ba", "%bb", "%bc", "%bd", "%be", "%bf", + "%c0", "%c1", "%c2", "%c3", "%c4", "%c5", "%c6", "%c7", + "%c8", "%c9", "%ca", "%cb", "%cc", "%cd", "%ce", "%cf", + "%d0", "%d1", "%d2", "%d3", "%d4", "%d5", "%d6", "%d7", + "%d8", "%d9", "%da", "%db", "%dc", "%dd", "%de", "%df", + "%e0", "%e1", "%e2", "%e3", "%e4", "%e5", "%e6", "%e7", + "%e8", "%e9", "%ea", "%eb", "%ec", "%ed", "%ee", "%ef", + "%f0", "%f1", "%f2", "%f3", "%f4", "%f5", "%f6", "%f7", + "%f8", "%f9", "%fa", "%fb", "%fc", "%fd", "%fe", "%ff" }; char *fmt(const char *format, ...) -- 2.3.1.308.g754cd77 From Jason at zx2c4.com Mon Mar 9 17:41:20 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Mar 2015 17:41:20 +0100 Subject: [PATCH 00/13] Fixes for problems detected by Sparse In-Reply-To: References: Message-ID: Great idea. Merged. Thanks John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Mon Mar 9 20:39:29 2015 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 9 Mar 2015 15:39:29 -0400 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150308104520.GK1369@serenity.lan> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> <20150307233510.GU3567@zaya.teonanacatl.net> <20150308104520.GK1369@serenity.lan> Message-ID: <20150309193929.GW3567@zaya.teonanacatl.net> John Keeping wrote: > On Sat, Mar 07, 2015 at 06:35:10PM -0500, Todd Zullinger wrote: >> But while we're on the subject, are there PGP signatures available for >> the cgit tarballs themselves? I know the git tags are signed, but I >> don't think I've seen detached signatures for the tarballs. In this >> case, how does a user become "happy that the CGit distribution they >> have is trustworthy"? The cgit tarball download isn't available via >> https either, which might be a reasonable answer in the absence of a >> detached git signature. >> >> Without a signature on the tarball or some other method to verify the >> cgit tarball, the sha256 of the git tarball included in the cgit >> Makefile is more or less only useful as a basic download integrity >> check (in which case sha256 is mild overkill). >> >> None of this is to say that this patch isn't a step in the right >> direction. It certainly helps to display a nicer error message if a >> user receives a corrupted git tarball. It's just important that users >> don't confuse this with providing any real authentication of the git >> tarball. > > I'm not sure this is true. Providing that the CGit tarball is trusted, > then I think this does provide sufficient authentication of the Git > tarball. If the CGit tarball isn't trusted, then all bets are off > anyway. Agreed. The caveat is that I'm not sure there is a convenient method for end-users or packagers to verify the authenticity of a cgit tarball. Those on the list can check the PGP signature on the announcement mail and then use the included SHA1 to check the tarball, but doing that as a non-list member isn't as easy due to many list archives stripping or mangling PGP signatures. I tried doing this with the 0.11 announcement from the Mailman and Gmane archives now and wasn't successful. Posting a detached PGP signature for the tarball would improve the ability for users to trust and verify the cgit tarball. It's not a blocker for your patch, but it would make it significantly more useful, so I thought I would broach the subject. ;) Thank you for all of your work on cgit. It's very nice to see it continue to improve, with even the smallest details getting attention. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now don't say you can't swear off drinking; it's easy. I've done it a thousand times. -- W.C. Fields From john at keeping.me.uk Mon Mar 9 21:49:46 2015 From: john at keeping.me.uk (John Keeping) Date: Mon, 9 Mar 2015 20:49:46 +0000 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150309193929.GW3567@zaya.teonanacatl.net> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> <20150307233510.GU3567@zaya.teonanacatl.net> <20150308104520.GK1369@serenity.lan> <20150309193929.GW3567@zaya.teonanacatl.net> Message-ID: <20150309204901.GL1369@serenity.lan> On Mon, Mar 09, 2015 at 03:39:29PM -0400, Todd Zullinger wrote: > Those on the list can check the PGP signature on the announcement mail > and then use the included SHA1 to check the tarball, but doing that as > a non-list member isn't as easy due to many list archives stripping or > mangling PGP signatures. I tried doing this with the 0.11 > announcement from the Mailman and Gmane archives now and wasn't > successful. It turns out that GMane mangles the list address in the message, so it is possible to validate it but it's not straightforward: curl http://article.gmane.org/gmane.comp.version-control.cgit/2387/raw | sed -e 's/cgit[^ ]*@public.gmane.org/cgit at lists.zx2c4.com/' | gpg --verify > Posting a detached PGP signature for the tarball would improve the > ability for users to trust and verify the cgit tarball. It's not a > blocker for your patch, but it would make it significantly more > useful, so I thought I would broach the subject. ;) It seems that Jason currently relies on CGit to generate the tarballs by pointing to http://git.zx2c4.com/cgit/refs/tags, which means that a signature isn't guaranteed to remain correct (Git has subtly changed the tar encoding in the past and could do so again). There's a recent thread on the Git mailing list about a way to handle this better[0], but there isn't any code yet AFAIK. [0] http://thread.gmane.org/gmane.comp.version-control.git/264533 From Jason at zx2c4.com Mon Mar 9 23:30:11 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Mar 2015 23:30:11 +0100 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307233510.GU3567@zaya.teonanacatl.net> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> <20150307233510.GU3567@zaya.teonanacatl.net> Message-ID: On Mar 8, 2015 12:35 AM, "Todd Zullinger" wrote: > But while we're on the subject, are there PGP signatures available for the cgit tarballs themselves? I include a sha256 of the tarball in the announcement emails. Those emails are pgp signed. My pgp key is embedded in the repo, as well, and it's verifiable that all announce emails have been signed with the same key. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason at zx2c4.com Mon Mar 9 23:32:44 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Mar 2015 23:32:44 +0100 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150309204901.GL1369@serenity.lan> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> <20150307233510.GU3567@zaya.teonanacatl.net> <20150308104520.GK1369@serenity.lan> <20150309193929.GW3567@zaya.teonanacatl.net> <20150309204901.GL1369@serenity.lan> Message-ID: On Mar 9, 2015 9:49 PM, "John Keeping" wrote: > It turns out that GMane mangles the list address in the message, Better archives: http://lists.zx2c4.com/pipermail/cgit/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason at zx2c4.com Mon Mar 9 23:34:07 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Mar 2015 23:34:07 +0100 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> <20150307233510.GU3567@zaya.teonanacatl.net> <20150308104520.GK1369@serenity.lan> <20150309193929.GW3567@zaya.teonanacatl.net> <20150309204901.GL1369@serenity.lan> Message-ID: Oh, hah, my pipermail does the same. That's annoying. I'll change up the release announcement next time to avoid that. On Mar 9, 2015 11:32 PM, "Jason A. Donenfeld" wrote: > > On Mar 9, 2015 9:49 PM, "John Keeping" wrote: > > It turns out that GMane mangles the list address in the message, > > Better archives: > http://lists.zx2c4.com/pipermail/cgit/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Mon Mar 9 23:42:48 2015 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 9 Mar 2015 18:42:48 -0400 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: Message-ID: <20150309224248.GY3567@zaya.teonanacatl.net> Jason A. Donenfeld wrote: > On Mar 8, 2015 12:35 AM, "Todd Zullinger" wrote: >> But while we're on the subject, are there PGP signatures available >> for the cgit tarballs themselves? > > I include a sha256 of the tarball in the announcement emails. Those > emails are pgp signed. My pgp key is embedded in the repo, as well, > and it's verifiable that all announce emails have been signed with > the same key. (It's a SHA1, isn't it? Not that I care terribly about that part, other than a general preference for SHA256. :) More importantly is that verifying the PGP signature from an archive is not always easy. More often than not, list archives introduce subtle whitespace damage or worse. The other point that John made is more interesting. If cgit generates a tarball on demand, aren't there opportunities for the hash in the announcement mail (or a detactch signature) to become invalid? I belive that git archive has made changes in the past to avoid including the timestamp in the gzip archive, which helps. I don't know if there are other ways this could change. In the end, I don't know if it's a problem that can be solved in a way that doesn't cause more work for you as a maintainer or the other fine folks who are contributing. That's certainly not my intention. ;) > On Mar 9, 2015 9:49 PM, "John Keeping" wrote: >> It turns out that GMane mangles the list address in the message, > > Better archives: > http://lists.zx2c4.com/pipermail/cgit/ I tried that earlier, before posting and found that it munges things too. Mailman's munging is often due to whitespace changes and are hard to avoid. Maybe the change to hyperkitty in Mailman 3 will improve this aspect of the archives. ;) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damn you and your estrogenical treachery! -- Stewie Griffin From mricon at kernel.org Wed Mar 11 16:25:20 2015 From: mricon at kernel.org (Konstantin Ryabitsev) Date: Wed, 11 Mar 2015 11:25:20 -0400 Subject: [PATCH] Check SHA256 sum of git-$VER.tar.gz after downloading In-Reply-To: <20150307182002.GJ1369@serenity.lan> References: <0146555fda82120aa6ff6a7e9761d00d53ced865.1425739601.git.john@keeping.me.uk> <20150307155926.6430.47439@typhoon> <20150307170259.GI1369@serenity.lan> <20150307174932.8657.41364@typhoon> <20150307182002.GJ1369@serenity.lan> Message-ID: <55005E60.2020504@kernel.org> On 07/03/15 01:20 PM, John Keeping wrote: > I still think we can't rely on `gpg --recv-keys` though, we would have > to distribute the key with CGit and possible also do something to avoid > importing it into the user's keyring by default. Here's 2 Canadian cents from the guy who is in charge of putting those .sign files in place. :) You can do it this way: 1. Create a pubring with Junio's key in it, like so: gpg --export 96AFE6CB > gitsig.gpg 2. Distribute gitsig.gpg with cgit 3. In the makefile, do something like this (e.g. for git-2.3.2): xz -cd git-2.3.2.tar.xz | gpgv --homedir=/tmp --keyring=./gitsig.gpg --status-fd=1 git-2.3.2.tar.sign - | grep '^\[GNUPG:\] GOODSIG' If the last grep exits with 0, you're good. Note, that the "grep GOODSIG" part is important if you care to check for key expiration. Default gpgv behaviour is to exit with 0 even if the key used to sign the archive has long since expired or has been revoked (yeah!). Grepping for "GOODSIG" will do the right thing but will also break your builds when Junio's key expires in September. :) If you don't care about such levels of paranoia, you can omit the "grep" and --status-fd=1 part and just rely on gpgv exit code. It's good enough for most people. Extra note: instead of using --homedir=/tmp, use a temporary dir created during make, in order to avoid potential security risks with someone spiking /tmp with a pubring.gpg. Hope this helps. Best, -- Konstantin Ryabitsev Linux Foundation Collab Projects Montr?al, Qu?bec From Jason at zx2c4.com Fri Mar 13 16:27:21 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 13 Mar 2015 16:27:21 +0100 Subject: [ANNOUNCE] CGIT v0.11.2 Released Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi folks, CGit 0.11.2 is now available, with numerous bug fixes. == CGit on the Web == * homepage: http://git.zx2c4.com/cgit/about/ * git repository: http://git.zx2c4.com/cgit/ * git clone: git://git.zx2c4.com/cgit * mailing list: cgit at lists.zx2c4.com * mailing list subscribe: http://lists.zx2c4.com/mailman/listinfo/cgit == ChangeLog v0.11.2 == 22 files changed, 444 insertions(+), 92 deletions(-) Additions: * New sample filter: filters/gentoo-ldap-authentication.lua This filter shows how you might use lualdap for real authentication. Changes: * Uses internally Git 2.3.2 * No longer display blank links for submodules when there's no way of resolving the submodule location. Bug fixes: * Numerous code quality fixes from sparse * Take into account leading slashes when comptuing links * Set up environment variables before making clone urls == Downloading == * http://git.zx2c4.com/cgit/snapshot/cgit-0.11.2.tar.xz sha256: 2e126e770693d7296c7eb5eb83b809410aef29870bfe8f54da072a3f4d813e3b * For verification git tag v0.11.2 is signed with my public key: zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc Thanks to everyone who contributed to this release! Jason Donenfeld -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBCAAGBQJVAwHVAAoJEEn8cBKl3gOucJUP+Pb4RHICgKRFKUsLiShVcN/T tlv97VWfTJ/KukDJIfWe20Wgb6PdDrOxVjzexbDXdg5bnJIti8PKuTzHvmoFyUnH PMQUESvFWHm0sUy22VGzpi45BrUi/79J9ioxqbrZne4l5Yz+AlE26Rj7BYeFqlGN JFQmTBeDk4K0LLdf7YiO281oWWDz33AQRY2TpWtD0fpdo3tHOjbHVBT4Pf1p1cZ3 kEVVk/VEpitgV+wzEgiDfhj5E02guYeWJwZcABUruzPozAlpkxqCr2W0AqcLD+hy va3YtntvYjI/c6PkUFoUCvOwmjqqOaWq2uZFqf3IqWEuHsDOKTqV0F9to0ed4vnj HulF3EdEORk3ST4EHeJpN1WDsGLWByCsMC3ChvtNVspWEa14kqnDsdHu99AVqajQ VFxftJyLIVWQ+WlaITZygLR+qWtqIU7w6Zhk7u4SQi79ZX6q4WIthzSJJhIJVPSM BWml+SrooLp1JVm6RNNgSCTgpG20pbAGGgLlSLJAbZtDBpMmvr+tKe8I92sai3aE AebSc9JeplVgEJn+nh74SAe6l5yIR+/z1rTogQ4zJkvN4AI9WrzET4OzmadIemg4 jq0yoKAQiRqHOOk1jOtHQZGIdWsatBn4jj7U8f05GhFhuBTpw1OpQiQVSjKN+cLV bf0YzylhVgfGASw60FE= =nhxe -----END PGP SIGNATURE----- From thuban at yeuxdelibad.net Sat Mar 14 09:25:49 2015 From: thuban at yeuxdelibad.net (Thuban) Date: Sat, 14 Mar 2015 09:25:49 +0100 Subject: cgit and nginx on debian Message-ID: <20150314082549.GB2814@localhost> Hi, I am trying to self-host my git repos, but I can't figure how to achieve this. Yes, there are many tutorials, but no one works in the end. What I need : - Clone over ssh - Clone over http - cgit on http://git.mydomain.com For now, I have installer nginx, cgit and fcgiwrap. I have access to cgit index page, but as soon as I wan't to go further (click on a repo, on tree or commit...), it fails. The url seems broken, because i repeat itself, ie : http://git.mydomain.com/shaarlyp/shaarlyp/tree/ Here is my nginx config : server { listen 80; server_name localhost; index cgit.cgi; root /usr/share/cgit; try_files $uri @cgit; location @cgit { include fastcgi_params; fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi; fastcgi_param PATH_INFO $uri; fastcgi_param QUERY_STRING $args; fastcgi_param HTTP_HOST $server_name; fastcgi_pass unix:/run/fcgiwrap.socket; } } cgit is installed via debian jessie package. Do you have any recent documentation, or any advice? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub From luky-37 at hotmail.com Sat Mar 14 09:28:17 2015 From: luky-37 at hotmail.com (Lukas Tribus) Date: Sat, 14 Mar 2015 09:28:17 +0100 Subject: cgit and nginx on debian In-Reply-To: <20150314082549.GB2814@localhost> References: <20150314082549.GB2814@localhost> Message-ID: > For now, I have installer nginx, cgit and fcgiwrap. I have access to > cgit index page, but as soon as I wan't to go further (click on a repo, > on tree or commit...), it fails. The url seems broken, because i repeat > itself, ie : http://git.mydomain.com/shaarlyp/shaarlyp/tree/ > > Here is my nginx config : > > server { > listen 80; > server_name localhost; > index cgit.cgi; > > root /usr/share/cgit; > try_files $uri @cgit; > > location @cgit { > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi; > fastcgi_param PATH_INFO $uri; > fastcgi_param QUERY_STRING $args; > fastcgi_param HTTP_HOST $server_name; > fastcgi_pass unix:/run/fcgiwrap.socket; > } > } > > cgit is installed via debian jessie package. > > Do you have any recent documentation, or any advice? http://lists.zx2c4.com/pipermail/cgit/2015-January/002345.html Lukas From thuban at yeuxdelibad.net Sat Mar 14 11:00:23 2015 From: thuban at yeuxdelibad.net (Thuban) Date: Sat, 14 Mar 2015 11:00:23 +0100 Subject: cgit and nginx on debian In-Reply-To: References: <20150314082549.GB2814@localhost> Message-ID: <20150314100023.GE2814@localhost> * Lukas Tribus le [14-03-2015 09:28:17 +0100]: > > > For now, I have installer nginx, cgit and fcgiwrap. I have access to > > cgit index page, but as soon as I wan't to go further (click on a repo, > > on tree or commit...), it fails. The url seems broken, because i repeat > > itself, ie : http://git.mydomain.com/shaarlyp/shaarlyp/tree/ > > > > Here is my nginx config : > > > > server { > > listen 80; > > server_name localhost; > > index cgit.cgi; > > > > root /usr/share/cgit; > > try_files $uri @cgit; > > > > location @cgit { > > include fastcgi_params; > > fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi; > > fastcgi_param PATH_INFO $uri; > > fastcgi_param QUERY_STRING $args; > > fastcgi_param HTTP_HOST $server_name; > > fastcgi_pass unix:/run/fcgiwrap.socket; > > } > > } > > > > cgit is installed via debian jessie package. > > > > Do you have any recent documentation, or any advice? > > http://lists.zx2c4.com/pipermail/cgit/2015-January/002345.html > > > Lukas Ok, after adding virtual-root=/ to /etc/cgitrc, now url seems ok. But still, when I click on "tree" or "log", I see the message "No repositories found". I can't figure what's wrong here... Regards. -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub From thuban at yeuxdelibad.net Sat Mar 14 14:01:02 2015 From: thuban at yeuxdelibad.net (Thuban) Date: Sat, 14 Mar 2015 14:01:02 +0100 Subject: cgit and nginx on debian In-Reply-To: <20150314100023.GE2814@localhost> References: <20150314082549.GB2814@localhost> <20150314100023.GE2814@localhost> Message-ID: <20150314130102.GA20292@localhost> * Thuban le [14-03-2015 11:00:23 +0100]: > * Lukas Tribus le [14-03-2015 09:28:17 +0100]: > > > > > For now, I have installer nginx, cgit and fcgiwrap. I have access to > > > cgit index page, but as soon as I wan't to go further (click on a repo, > > > on tree or commit...), it fails. The url seems broken, because i repeat > > > itself, ie : http://git.mydomain.com/shaarlyp/shaarlyp/tree/ > > > > > > Here is my nginx config : > > > > > > server { > > > listen 80; > > > server_name localhost; > > > index cgit.cgi; > > > > > > root /usr/share/cgit; > > > try_files $uri @cgit; > > > > > > location @cgit { > > > include fastcgi_params; > > > fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi; > > > fastcgi_param PATH_INFO $uri; > > > fastcgi_param QUERY_STRING $args; > > > fastcgi_param HTTP_HOST $server_name; > > > fastcgi_pass unix:/run/fcgiwrap.socket; > > > } > > > } > > > > > > cgit is installed via debian jessie package. > > > > > > Do you have any recent documentation, or any advice? > > > > http://lists.zx2c4.com/pipermail/cgit/2015-January/002345.html > > > > > > Lukas > > Ok, after adding virtual-root=/ to /etc/cgitrc, now url seems ok. > But still, when I click on "tree" or "log", I see the message "No > repositories found". I can't figure what's wrong here... > > Regards. > > -- > Thuban > PubKey : http://yeuxdelibad.net/Divers/thuban.pub > _______________________________________________ > CGit mailing list > CGit at lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/cgit Problem solved, I had to remove this option : remove-suffix=1 Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub From list at eworm.de Sat Mar 14 17:21:42 2015 From: list at eworm.de (Christian Hesse) Date: Sat, 14 Mar 2015 17:21:42 +0100 Subject: [PATCH 1/1] git: update to v2.3.3 Message-ID: <1426350102-25010-1-git-send-email-list@eworm.de> From: Christian Hesse Update to git version v2.3.3, no changes required. Signed-off-by: Christian Hesse --- Makefile | 2 +- git | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 043601f..1a900f8 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ htmldir = $(docdir) pdfdir = $(docdir) mandir = $(prefix)/share/man SHA1_HEADER = -GIT_VER = 2.3.2 +GIT_VER = 2.3.3 GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.gz INSTALL = install COPYTREE = cp -r diff --git a/git b/git index 1165ae6..bb85775 160000 --- a/git +++ b/git @@ -1 +1 @@ -Subproject commit 1165ae6f3d42e0eb0ddfc2d4e6dfa8bd0b88eb60 +Subproject commit bb8577532add843833ebf8b5324f94f84cb71ca0 -- 2.3.2 From Jason at zx2c4.com Sat Mar 14 17:55:52 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sat, 14 Mar 2015 17:55:52 +0100 Subject: [PATCH 1/1] git: update to v2.3.3 In-Reply-To: <1426350102-25010-1-git-send-email-list@eworm.de> References: <1426350102-25010-1-git-send-email-list@eworm.de> Message-ID: Merged, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at eworm.de Wed Mar 18 18:08:48 2015 From: list at eworm.de (Christian Hesse) Date: Wed, 18 Mar 2015 18:08:48 +0100 Subject: [PATCH 1/1] ui-shared: allow remote refs in branch switcher Message-ID: <1426698528-12881-1-git-send-email-list@eworm.de> From: Christian Hesse Signed-off-by: Christian Hesse --- ui-shared.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ui-shared.c b/ui-shared.c index 1dd8722..ac5a287 100644 --- a/ui-shared.c +++ b/ui-shared.c @@ -895,6 +895,8 @@ static void print_header(void) cgit_add_hidden_formfields(0, 1, ctx.qry.page); html(" "); html(""); html(""); -- 2.3.3 From Jason at zx2c4.com Wed Mar 18 18:23:22 2015 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 18 Mar 2015 18:23:22 +0100 Subject: [PATCH 1/1] ui-shared: allow remote refs in branch switcher In-Reply-To: <1426698528-12881-1-git-send-email-list@eworm.de> References: <1426698528-12881-1-git-send-email-list@eworm.de> Message-ID: Thanks, merged. From stefan.naewe at gmail.com Fri Mar 20 17:39:53 2015 From: stefan.naewe at gmail.com (Stefan Naewe) Date: Fri, 20 Mar 2015 17:39:53 +0100 Subject: [PATCH] ui-commit: display commit notes as 'raw' Message-ID: <1426869593-10432-1-git-send-email-stefan.naewe@gmail.com> When the git function format_display_notes() is called with a value != 0 as the last argument ('raw') the notes text gets displayed w/o an additional 'Notes:' header. This seems to be better suited for our needs since we're already displaying a similar header. Signed-off-by: Stefan Naewe --- ui-commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui-commit.c b/ui-commit.c index d5a888d..4b40133 100644 --- a/ui-commit.c +++ b/ui-commit.c @@ -37,7 +37,7 @@ void cgit_print_commit(char *hex, const char *prefix) } info = cgit_parse_commit(commit); - format_display_notes(sha1, ¬es, PAGE_ENCODING, 0); + format_display_notes(sha1, ¬es, PAGE_ENCODING, 1); load_ref_decorations(DECORATE_FULL_REFS); -- 2.3.3 From john at keeping.me.uk Fri Mar 20 22:29:50 2015 From: john at keeping.me.uk (John Keeping) Date: Fri, 20 Mar 2015 21:29:50 +0000 Subject: [PATCH] ui-commit: display commit notes as 'raw' In-Reply-To: <1426869593-10432-1-git-send-email-stefan.naewe@gmail.com> References: <1426869593-10432-1-git-send-email-stefan.naewe@gmail.com> Message-ID: <20150320212950.GA1344@serenity> On Fri, Mar 20, 2015 at 05:39:53PM +0100, Stefan Naewe wrote: > When the git function format_display_notes() is called > with a value != 0 as the last argument ('raw') the notes text > gets displayed w/o an additional 'Notes:' header. This seems > to be better suited for our needs since we're already displaying > a similar header. What happens when there are multiple display notes refs? It seems that without "raw", format_note() puts the name of the ref in the header it prints (if it's not the default notes ref). It's possible that the correct answer is that we don't care about that case, but it is potentially a regression for people who want to display multiple notes. > Signed-off-by: Stefan Naewe > --- > ui-commit.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ui-commit.c b/ui-commit.c > index d5a888d..4b40133 100644 > --- a/ui-commit.c > +++ b/ui-commit.c > @@ -37,7 +37,7 @@ void cgit_print_commit(char *hex, const char *prefix) > } > info = cgit_parse_commit(commit); > > - format_display_notes(sha1, ¬es, PAGE_ENCODING, 0); > + format_display_notes(sha1, ¬es, PAGE_ENCODING, 1); > > load_ref_decorations(DECORATE_FULL_REFS); > From stefan.naewe at gmail.com Sat Mar 21 14:11:51 2015 From: stefan.naewe at gmail.com (Stefan Naewe) Date: Sat, 21 Mar 2015 14:11:51 +0100 Subject: [PATCH] ui-commit: display commit notes as 'raw' In-Reply-To: <20150320212950.GA1344@serenity> References: <1426869593-10432-1-git-send-email-stefan.naewe@gmail.com> <20150320212950.GA1344@serenity> Message-ID: On Fri, Mar 20, 2015 at 10:29 PM, John Keeping wrote: > On Fri, Mar 20, 2015 at 05:39:53PM +0100, Stefan Naewe wrote: >> When the git function format_display_notes() is called >> with a value != 0 as the last argument ('raw') the notes text >> gets displayed w/o an additional 'Notes:' header. This seems >> to be better suited for our needs since we're already displaying >> a similar header. > > What happens when there are multiple display notes refs? It seems that > without "raw", format_note() puts the name of the ref in the header it > prints (if it's not the default notes ref). That's true for 'git show --notes=...' for example. But how would you specify the name of the notes ref in cgit ? > It's possible that the correct answer is that we don't care about that > case, but it is potentially a regression for people who want to display > multiple notes. Attached are two screenshots of commit notes added with 'git notes add..' for the first line and 'git notes append...' for the second line. That particular commit also has another note attached in the 'refs/notes/todo' namespace. My opinion about this topic: I really like the way cgit displays the commit notes but not the double "Notes" header line. Regards, Stefan -- ---------------------------------------------------------------- python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')" -------------- next part -------------- A non-text attachment was scrubbed... Name: shot-cgit-notes.png Type: image/png Size: 11634 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shot-cgit-notes-raw.png Type: image/png Size: 7481 bytes Desc: not available URL: From john at keeping.me.uk Sat Mar 21 14:19:38 2015 From: john at keeping.me.uk (John Keeping) Date: Sat, 21 Mar 2015 13:19:38 +0000 Subject: [PATCH] ui-commit: display commit notes as 'raw' In-Reply-To: References: <1426869593-10432-1-git-send-email-stefan.naewe@gmail.com> <20150320212950.GA1344@serenity> Message-ID: <20150321131938.GB1344@serenity> On Sat, Mar 21, 2015 at 02:11:51PM +0100, Stefan Naewe wrote: > On Fri, Mar 20, 2015 at 10:29 PM, John Keeping wrote: > > On Fri, Mar 20, 2015 at 05:39:53PM +0100, Stefan Naewe wrote: > >> When the git function format_display_notes() is called > >> with a value != 0 as the last argument ('raw') the notes text > >> gets displayed w/o an additional 'Notes:' header. This seems > >> to be better suited for our needs since we're already displaying > >> a similar header. > > > > What happens when there are multiple display notes refs? It seems that > > without "raw", format_note() puts the name of the ref in the header it > > prints (if it's not the default notes ref). > That's true for 'git show --notes=...' for example. > > But how would you specify the name of the notes ref in cgit ? git config --add notes.displayRef ... > > It's possible that the correct answer is that we don't care about that > > case, but it is potentially a regression for people who want to display > > multiple notes. > > Attached are two screenshots of commit notes added with 'git notes > add..' for the first line and > 'git notes append...' for the second line. That particular commit also > has another note > attached in the 'refs/notes/todo' namespace. > > My opinion about this topic: I really like the way cgit displays the > commit notes but not the > double "Notes" header line. From stefan.naewe at gmail.com Sat Mar 21 16:37:39 2015 From: stefan.naewe at gmail.com (Stefan Naewe) Date: Sat, 21 Mar 2015 16:37:39 +0100 Subject: [PATCH] ui-commit: display commit notes as 'raw' In-Reply-To: <20150321131938.GB1344@serenity> References: <1426869593-10432-1-git-send-email-stefan.naewe@gmail.com> <20150320212950.GA1344@serenity> <20150321131938.GB1344@serenity> Message-ID: On Sat, Mar 21, 2015 at 2:19 PM, John Keeping wrote: > On Sat, Mar 21, 2015 at 02:11:51PM +0100, Stefan Naewe wrote: >> On Fri, Mar 20, 2015 at 10:29 PM, John Keeping wrote: >> > On Fri, Mar 20, 2015 at 05:39:53PM +0100, Stefan Naewe wrote: >> >> When the git function format_display_notes() is called >> >> with a value != 0 as the last argument ('raw') the notes text >> >> gets displayed w/o an additional 'Notes:' header. This seems >> >> to be better suited for our needs since we're already displaying >> >> a similar header. >> > >> > What happens when there are multiple display notes refs? It seems that >> > without "raw", format_note() puts the name of the ref in the header it >> > prints (if it's not the default notes ref). >> That's true for 'git show --notes=...' for example. >> >> But how would you specify the name of the notes ref in cgit ? > > git config --add notes.displayRef ... Thanks. That looks like attached. One without and one with my patch. Maybe we should drop the "Notes" headline that cgit generates, instead ? Stefan -- ---------------------------------------------------------------- python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')" -------------- next part -------------- A non-text attachment was scrubbed... Name: shot-cgit-notes-2refs.png Type: image/png Size: 10328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shot-cgit-notes-2refs-raw.png Type: image/png Size: 6340 bytes Desc: not available URL: From list at eworm.de Mon Mar 23 23:38:33 2015 From: list at eworm.de (Christian Hesse) Date: Mon, 23 Mar 2015 23:38:33 +0100 Subject: [PATCH 1/1] git: update to v2.3.4 Message-ID: <1427150313-5602-1-git-send-email-list@eworm.de> From: Christian Hesse Update to git version v2.3.4, no changes required. Signed-off-by: Christian Hesse --- Makefile | 2 +- git | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 1a900f8..fef75f2 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ htmldir = $(docdir) pdfdir = $(docdir) mandir = $(prefix)/share/man SHA1_HEADER = -GIT_VER = 2.3.3 +GIT_VER = 2.3.4 GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.gz INSTALL = install COPYTREE = cp -r diff --git a/git b/git index bb85775..3a52578 160000 --- a/git +++ b/git @@ -1 +1 @@ -Subproject commit bb8577532add843833ebf8b5324f94f84cb71ca0 +Subproject commit 3a52578eef9b65ad449853e4a3a923d8e1eb2a22 -- 2.3.3 From lists at necoro.eu Tue Mar 24 07:02:26 2015 From: lists at necoro.eu (=?windows-1252?Q?Ren=E9_Neumann?=) Date: Tue, 24 Mar 2015 07:02:26 +0100 Subject: [PATCH 2/2 v3] log: allow users to follow a file In-Reply-To: <20130420122135.GI2278@serenity.lan> References: <63567740b5b2b2b79eafff7a00148ef8a7b71bad.1366452850.git.john@keeping.me.uk> <20130420122135.GI2278@serenity.lan> Message-ID: <5510FDF2.5010303@necoro.eu> Hi all, when cleaning up my cgit installation (and upgrading to a recent version), I noted that I had the following patch applied. A quick search revealed, that it has not found its way into cgit. Was this an oversight, or was it on purpose? - Ren? Am 20.04.2013 um 14:21 schrieb John Keeping: > Teach the "log" UI to behave in the same way as "git log --follow", when > given a suitable instruction by the user. The default behaviour remains > to show the log without following renames, but the follow behaviour can > be activated by following a link in the page header. > > Follow is not the default because outputting merges in follow mode is > tricky ("git log --follow" will not show merges). We also disable the > graph in follow mode because the commit graph is not simplified so we > end up with frequent gaps in the graph and many lines that do not > connect with any commits we're actually showing. > > We also teach the "diff" and "commit" UIs to respect the follow flag on > URLs, causing the single-file version of these UIs to detect renames. > This feature is needed only for commits that rename the path we're > interested in. > > For commits before the file has been renamed (i.e. that appear later in > the log list) we change the file path in the links from the log to point > to the old name; this means that links to commits always limit by the > path known to that commit. If we didn't do this we would need to walk > down the log diff'ing every commit whenever we want to show a commit. > The drawback is that the "Log" link in the top bar of such a page links > to the log limited by the old name, so it will only show pre-rename > commits. I consider this a reasonable trade-off since the "Back" button > still works and the log matches the path displayed in the top bar. > > Since following renames requires running diff on every commit we > consider, I've added a knob to the configuration file to globally > enable/disable this feature. Note that we may consider a large number > of commits the revision walking machinery no longer performs any path > limitation so we have to examine every commit until we find a page full > of commits that affect the target path or something related to it. > > Suggested-by: Ren? Neumann > Signed-off-by: John Keeping > --- > I've just realised I didn't commit a final fixup to this before sending > it out. The difference is in handle_rename() which doesn't leak memory > in this version. > > cgit.c | 4 ++ > cgit.h | 2 + > cgitrc.5.txt | 4 ++ > ui-diff.c | 35 +++++++++++++++ > ui-log.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ > ui-refs.c | 2 +- > ui-repolist.c | 2 +- > ui-shared.c | 28 ++++++++++-- > ui-shared.h | 2 +- > ui-tree.c | 2 +- > 10 files changed, 197 insertions(+), 20 deletions(-) > > diff --git a/cgit.c b/cgit.c > index 6f44ef2..81312bb 100644 > --- a/cgit.c > +++ b/cgit.c > @@ -171,6 +171,8 @@ static void config_cb(const char *name, const char *value) > ctx.cfg.snapshots = cgit_parse_snapshots_mask(value); > else if (!strcmp(name, "enable-filter-overrides")) > ctx.cfg.enable_filter_overrides = atoi(value); > + else if (!strcmp(name, "enable-follow-links")) > + ctx.cfg.enable_follow_links = atoi(value); > else if (!strcmp(name, "enable-http-clone")) > ctx.cfg.enable_http_clone = atoi(value); > else if (!strcmp(name, "enable-index-links")) > @@ -338,6 +340,8 @@ static void querystring_cb(const char *name, const char *value) > ctx.qry.context = atoi(value); > } else if (!strcmp(name, "ignorews")) { > ctx.qry.ignorews = atoi(value); > + } else if (!strcmp(name, "follow")) { > + ctx.qry.follow = atoi(value); > } > } > > diff --git a/cgit.h b/cgit.h > index b56e756..c0758b0 100644 > --- a/cgit.h > +++ b/cgit.h > @@ -163,6 +163,7 @@ struct cgit_query { > int show_all; > int context; > int ignorews; > + int follow; > char *vpath; > }; > > @@ -203,6 +204,7 @@ struct cgit_config { > int case_sensitive_sort; > int embedded; > int enable_filter_overrides; > + int enable_follow_links; > int enable_http_clone; > int enable_index_links; > int enable_index_owner; > diff --git a/cgitrc.5.txt b/cgitrc.5.txt > index 39b031e..48ef249 100644 > --- a/cgitrc.5.txt > +++ b/cgitrc.5.txt > @@ -121,6 +121,10 @@ 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-follow-links:: > + Flag which, when set to "1", allows users to follow a file in the log > + view. Default value: "0". > + > enable-http-clone:: > If set to "1", cgit will act as an dumb HTTP endpoint for git clones. > If you use an alternate way of serving git repositories, you may wish > diff --git a/ui-diff.c b/ui-diff.c > index 8b38209..2d75f34 100644 > --- a/ui-diff.c > +++ b/ui-diff.c > @@ -36,6 +36,7 @@ static struct fileinfo { > > static int use_ssdiff = 0; > static struct diff_filepair *current_filepair; > +static const char *current_prefix; > > struct diff_filespec *cgit_get_current_old_file(void) > { > @@ -132,11 +133,30 @@ static void count_diff_lines(char *line, int len) > } > } > > +static int show_filepair(struct diff_filepair *pair) > +{ > + /* Always show if we have no limiting prefix. */ > + if (!current_prefix) > + return 1; > + > + /* Show if either path in the pair begins with the prefix. */ > + if (!prefixcmp(pair->one->path, current_prefix) || > + !prefixcmp(pair->two->path, current_prefix)) > + return 1; > + > + /* Otherwise we don't want to show this filepair. */ > + return 0; > +} > + > static void inspect_filepair(struct diff_filepair *pair) > { > int binary = 0; > unsigned long old_size = 0; > unsigned long new_size = 0; > + > + if (!show_filepair(pair)) > + return; > + > files++; > lines_added = 0; > lines_removed = 0; > @@ -279,6 +299,9 @@ static void filepair_cb(struct diff_filepair *pair) > int binary = 0; > linediff_fn print_line_fn = print_line; > > + if (!show_filepair(pair)) > + return; > + > current_filepair = pair; > if (use_ssdiff) { > cgit_ssdiff_header_begin(); > @@ -364,6 +387,18 @@ void cgit_print_diff(const char *new_rev, const char *old_rev, > unsigned long size; > struct commit *commit, *commit2; > > + /* > + * If "follow" is set then the diff machinery needs to examine the > + * entire commit to detect renames so we must limit the paths in our > + * own callbacks and not pass the prefix to the diff machinery. > + */ > + if (ctx.qry.follow && ctx.cfg.enable_follow_links) { > + current_prefix = prefix; > + prefix = ""; > + } else { > + current_prefix = NULL; > + } > + > if (!new_rev) > new_rev = ctx.qry.head; > get_sha1(new_rev, new_rev_sha1); > diff --git a/ui-log.c b/ui-log.c > index 2aa12c3..6bab166 100644 > --- a/ui-log.c > +++ b/ui-log.c > @@ -12,7 +12,7 @@ > #include "ui-shared.h" > #include "vector.h" > > -int files, add_lines, rem_lines; > +int files, add_lines, rem_lines, lines_counted; > > /* > * The list of available column colors in the commit graph. > @@ -66,7 +66,7 @@ void show_commit_decorations(struct commit *commit) > strncpy(buf, deco->name + 11, sizeof(buf) - 1); > cgit_log_link(buf, NULL, "branch-deco", buf, NULL, > ctx.qry.vpath, 0, NULL, NULL, > - ctx.qry.showmsg); > + ctx.qry.showmsg, 0); > } > else if (!prefixcmp(deco->name, "tag: refs/tags/")) { > strncpy(buf, deco->name + 15, sizeof(buf) - 1); > @@ -83,7 +83,7 @@ void show_commit_decorations(struct commit *commit) > cgit_log_link(buf, NULL, "remote-deco", NULL, > sha1_to_hex(commit->object.sha1), > ctx.qry.vpath, 0, NULL, NULL, > - ctx.qry.showmsg); > + ctx.qry.showmsg, 0); > } > else { > strncpy(buf, deco->name, sizeof(buf) - 1); > @@ -96,6 +96,74 @@ next: > } > } > > +static void handle_rename(struct diff_filepair *pair) > +{ > + /* > + * After we have seen a rename, we generate links to the previous > + * name of the file so that commit & diff views get fed the path > + * that is correct for the commit they are showing, avoiding the > + * need to walk the entire history leading back to every commit we > + * show in order detect renames. > + */ > + if (0 != strcmp(ctx.qry.vpath, pair->two->path)) { > + free(ctx.qry.vpath); > + ctx.qry.vpath = xstrdup(pair->two->path); > + } > + inspect_files(pair); > +} > + > +static int show_commit(struct commit *commit, struct rev_info *revs) > +{ > + struct commit_list *parents = commit->parents; > + struct commit *parent; > + int found = 0, saved_fmt; > + unsigned saved_flags = revs->diffopt.flags; > + > + > + /* Always show if we're not in "follow" mode with a single file. */ > + if (!ctx.qry.follow) > + return 1; > + > + /* > + * In "follow" mode, we don't show merges. This is consistent with > + * "git log --follow -- ". > + */ > + if (parents && parents->next) > + return 0; > + > + /* > + * If this is the root commit, do what rev_info tells us. > + */ > + if (!parents) > + return revs->show_root_diff; > + > + /* When we get here we have precisely one parent. */ > + parent = parents->item; > + parse_commit(parent); > + > + files = 0; > + add_lines = 0; > + rem_lines = 0; > + > + DIFF_OPT_SET(&revs->diffopt, RECURSIVE); > + diff_tree_sha1(parent->tree->object.sha1, > + commit->tree->object.sha1, > + "", &revs->diffopt); > + diffcore_std(&revs->diffopt); > + > + found = !diff_queue_is_empty(); > + saved_fmt = revs->diffopt.output_format; > + revs->diffopt.output_format = DIFF_FORMAT_CALLBACK; > + revs->diffopt.format_callback = cgit_diff_tree_cb; > + revs->diffopt.format_callback_data = handle_rename; > + diff_flush(&revs->diffopt); > + revs->diffopt.output_format = saved_fmt; > + revs->diffopt.flags = saved_flags; > + > + lines_counted = 1; > + return found; > +} > + > static void print_commit(struct commit *commit, struct rev_info *revs) > { > struct commitinfo *info; > @@ -173,7 +241,8 @@ static void print_commit(struct commit *commit, struct rev_info *revs) > cgit_print_age(commit->date, TM_WEEK * 2, FMT_SHORTDATE); > } > > - if (ctx.repo->enable_log_filecount || ctx.repo->enable_log_linecount) { > + if (!lines_counted && (ctx.repo->enable_log_filecount || > + ctx.repo->enable_log_linecount)) { > files = 0; > add_lines = 0; > rem_lines = 0; > @@ -324,7 +393,17 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > } > } > } > - if (commit_graph) { > + > + if (!path || !ctx.cfg.enable_follow_links) { > + /* > + * If we don't have a path, "follow" is a no-op so make sure > + * the variable is set to false to avoid needing to check > + * both this and whether we have a path everywhere. > + */ > + ctx.qry.follow = 0; > + } > + > + if (commit_graph && !ctx.qry.follow) { > static const char *graph_arg = "--graph"; > static const char *color_arg = "--color"; > vector_push(&vec, &graph_arg, 0); > @@ -342,7 +421,10 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > } > > if (path) { > + static const char *follow_arg = "--follow"; > static const char *double_dash_arg = "--"; > + if (ctx.qry.follow) > + vector_push(&vec, &follow_arg, 0); > vector_push(&vec, &double_dash_arg, 0); > vector_push(&vec, &path, 0); > } > @@ -356,10 +438,17 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > rev.commit_format = CMIT_FMT_DEFAULT; > rev.verbose_header = 1; > rev.show_root_diff = 0; > + rev.simplify_history = 1; > setup_revisions(vec.count, vec.data, &rev, NULL); > load_ref_decorations(DECORATE_FULL_REFS); > rev.show_decorations = 1; > rev.grep_filter.regflags |= REG_ICASE; > + > + rev.diffopt.detect_rename = 1; > + rev.diffopt.rename_limit = ctx.cfg.renamelimit; > + if (ctx.qry.ignorews) > + DIFF_XDL_SET(&rev.diffopt, IGNORE_WHITESPACE); > + > compile_grep_patterns(&rev.grep_filter); > prepare_revision_walk(&rev); > > @@ -377,11 +466,12 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > cgit_log_link(ctx.qry.showmsg ? "Collapse" : "Expand", NULL, > NULL, ctx.qry.head, ctx.qry.sha1, > ctx.qry.vpath, ctx.qry.ofs, ctx.qry.grep, > - ctx.qry.search, ctx.qry.showmsg ? 0 : 1); > + ctx.qry.search, ctx.qry.showmsg ? 0 : 1, > + ctx.qry.follow); > html(")"); > } > html("Author"); > - if (commit_graph) > + if (rev.graph) > html("Age"); > if (ctx.repo->enable_log_filecount) { > html("Files"); > @@ -396,15 +486,32 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > if (ofs<0) > ofs = 0; > > - for (i = 0; i < ofs && (commit = get_revision(&rev)) != NULL; i++) { > + for (i = 0; i < ofs && (commit = get_revision(&rev)) != NULL;) { > + if (show_commit(commit, &rev)) > + i++; > free(commit->buffer); > commit->buffer = NULL; > free_commit_list(commit->parents); > commit->parents = NULL; > } > > - for (i = 0; i < cnt && (commit = get_revision(&rev)) != NULL; i++) { > - print_commit(commit, &rev); > + for (i = 0; i < cnt && (commit = get_revision(&rev)) != NULL;) { > + /* > + * In "follow" mode, we must count the files and lines the > + * first time we invoke diff on a given commit, and we need > + * to do that to see if the commit touches the path we care > + * about, so we do it in show_commit. Hence we must clear > + * lines_counted here. > + * > + * This has the side effect of avoiding running diff twice > + * when we are both following renames and showing file > + * and/or line counts. > + */ > + lines_counted = 0; > + if (show_commit(commit, &rev)) { > + i++; > + print_commit(commit, &rev); > + } > free(commit->buffer); > commit->buffer = NULL; > free_commit_list(commit->parents); > @@ -417,7 +524,8 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > cgit_log_link("[prev]", NULL, NULL, ctx.qry.head, > ctx.qry.sha1, ctx.qry.vpath, > ofs - cnt, ctx.qry.grep, > - ctx.qry.search, ctx.qry.showmsg); > + ctx.qry.search, ctx.qry.showmsg, > + ctx.qry.follow); > html(""); > } > if ((commit = get_revision(&rev)) != NULL) { > @@ -425,14 +533,16 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern > cgit_log_link("[next]", NULL, NULL, ctx.qry.head, > ctx.qry.sha1, ctx.qry.vpath, > ofs + cnt, ctx.qry.grep, > - ctx.qry.search, ctx.qry.showmsg); > + ctx.qry.search, ctx.qry.showmsg, > + ctx.qry.follow); > html(""); > } > html(""); > } else if ((commit = get_revision(&rev)) != NULL) { > htmlf("", columns); > cgit_log_link("[...]", NULL, NULL, ctx.qry.head, NULL, > - ctx.qry.vpath, 0, NULL, NULL, ctx.qry.showmsg); > + ctx.qry.vpath, 0, NULL, NULL, ctx.qry.showmsg, > + ctx.qry.follow); > html("\n"); > } > > diff --git a/ui-refs.c b/ui-refs.c > index 0ae0612..f4eefd1 100644 > --- a/ui-refs.c > +++ b/ui-refs.c > @@ -71,7 +71,7 @@ static int print_branch(struct refinfo *ref) > return 1; > html(""); > cgit_log_link(name, NULL, NULL, name, NULL, NULL, 0, NULL, NULL, > - ctx.qry.showmsg); > + ctx.qry.showmsg, 0); > html(""); > > if (ref->object->type == OBJ_COMMIT) { > diff --git a/ui-repolist.c b/ui-repolist.c > index 47ca997..d96f252 100644 > --- a/ui-repolist.c > +++ b/ui-repolist.c > @@ -314,7 +314,7 @@ void cgit_print_repolist() > html(""); > cgit_summary_link("summary", NULL, "button", NULL); > cgit_log_link("log", NULL, "button", NULL, NULL, NULL, > - 0, NULL, NULL, ctx.qry.showmsg); > + 0, NULL, NULL, ctx.qry.showmsg, 0); > cgit_tree_link("tree", NULL, "button", NULL, NULL, NULL); > html(""); > } > diff --git a/ui-shared.c b/ui-shared.c > index 519eef7..04d0368 100644 > --- a/ui-shared.c > +++ b/ui-shared.c > @@ -284,7 +284,8 @@ void cgit_plain_link(const char *name, const char *title, const char *class, > > void cgit_log_link(const char *name, const char *title, const char *class, > const char *head, const char *rev, const char *path, > - int ofs, const char *grep, const char *pattern, int showmsg) > + int ofs, const char *grep, const char *pattern, int showmsg, > + int follow) > { > char *delim; > > @@ -313,6 +314,11 @@ void cgit_log_link(const char *name, const char *title, const char *class, > if (showmsg) { > html(delim); > html("showmsg=1"); > + delim = "&"; > + } > + if (follow) { > + html(delim); > + html("follow=1"); > } > html("'>"); > html_txt(name); > @@ -355,6 +361,10 @@ void cgit_commit_link(char *name, const char *title, const char *class, > html("ignorews=1"); > delim = "&"; > } > + if (ctx.qry.follow) { > + html(delim); > + html("follow=1"); > + } > html("'>"); > if (name[0] != '\0') > html_txt(name); > @@ -411,6 +421,10 @@ void cgit_diff_link(const char *name, const char *title, const char *class, > html("ignorews=1"); > delim = "&"; > } > + if (ctx.qry.follow) { > + html(delim); > + html("follow=1"); > + } > html("'>"); > html_txt(name); > html(""); > @@ -452,7 +466,7 @@ static void cgit_self_link(char *name, const char *title, const char *class, > ctx->qry.has_sha1 ? ctx->qry.sha1 : NULL, > ctx->qry.path, ctx->qry.ofs, > ctx->qry.grep, ctx->qry.search, > - ctx->qry.showmsg); > + ctx->qry.showmsg, ctx->qry.follow); > else if (!strcmp(ctx->qry.page, "commit")) > cgit_commit_link(name, title, class, ctx->qry.head, > ctx->qry.has_sha1 ? ctx->qry.sha1 : NULL, > @@ -854,7 +868,7 @@ void cgit_print_pageheader(struct cgit_context *ctx) > ctx->qry.sha1, NULL); > cgit_log_link("log", NULL, hc(ctx, "log"), ctx->qry.head, > NULL, ctx->qry.vpath, 0, NULL, NULL, > - ctx->qry.showmsg); > + ctx->qry.showmsg, ctx->qry.follow); > cgit_tree_link("tree", NULL, hc(ctx, "tree"), ctx->qry.head, > ctx->qry.sha1, ctx->qry.vpath); > cgit_commit_link("commit", NULL, hc(ctx, "commit"), > @@ -906,6 +920,14 @@ void cgit_print_pageheader(struct cgit_context *ctx) > html("

"); > html("path: "); > cgit_print_path_crumbs(ctx, ctx->qry.vpath); > + if (ctx->cfg.enable_follow_links && !strcmp(ctx->qry.page, "log")) { > + html(" ("); > + ctx->qry.follow = !ctx->qry.follow; > + cgit_self_link(ctx->qry.follow ? "follow" : "unfollow", > + NULL, NULL, ctx); > + ctx->qry.follow = !ctx->qry.follow; > + html(")"); > + } > html("

"); > } > html("

"); > diff --git a/ui-shared.h b/ui-shared.h > index 5987e77..3156846 100644 > --- a/ui-shared.h > +++ b/ui-shared.h > @@ -26,7 +26,7 @@ extern void cgit_plain_link(const char *name, const char *title, > extern void cgit_log_link(const char *name, const char *title, > const char *class, const char *head, const char *rev, > const char *path, int ofs, const char *grep, > - const char *pattern, int showmsg); > + const char *pattern, int showmsg, int follow); > extern void cgit_commit_link(char *name, const char *title, > const char *class, const char *head, > const char *rev, const char *path, > diff --git a/ui-tree.c b/ui-tree.c > index aa5dee9..ebb3e9b 100644 > --- a/ui-tree.c > +++ b/ui-tree.c > @@ -169,7 +169,7 @@ static int ls_item(const unsigned char *sha1, const char *base, int baselen, > html(""); > cgit_log_link("log", NULL, "button", ctx.qry.head, > walk_tree_ctx->curr_rev, fullpath.buf, 0, NULL, NULL, > - ctx.qry.showmsg); > + ctx.qry.showmsg, 0); > if (ctx.repo->max_stats) > cgit_stats_link("stats", NULL, "button", ctx.qry.head, > fullpath.buf); > From nicolas.dely at technicolor.com Mon Mar 30 19:15:27 2015 From: nicolas.dely at technicolor.com (Nicolas Dely) Date: Mon, 30 Mar 2015 19:15:27 +0200 Subject: unexpected cache issue when http errors Message-ID: <551984AF.6020203@technicolor.com> Hi, I would like to share an unexpected cache behaviour with this list and discuss about a solution. Indeed we are using cgit to provide a web interface to our internal user and also to provide file to our reviewboard server. We are experiencing some cache issue on static pages when data are not pushed yet to server but reviewboard tries to access these files/repositories. Cache is adding even 404, 401 or 500 error for static page, we can workaround this issue after reducing/setting static cache issue but it looks not very useful to cache http errors. Do you think it is possible to only cache when HTTP is 200 OK? Other ideas? PS: I've seen a cache issue (lock file) but nothing about http errors Regards Nicolas From john at keeping.me.uk Tue Mar 31 20:39:19 2015 From: john at keeping.me.uk (John Keeping) Date: Tue, 31 Mar 2015 19:39:19 +0100 Subject: unexpected cache issue when http errors In-Reply-To: <551984AF.6020203@technicolor.com> References: <551984AF.6020203@technicolor.com> Message-ID: <20150331183919.GB2248@serenity.lan> On Mon, Mar 30, 2015 at 07:15:27PM +0200, Nicolas Dely wrote: > I would like to share an unexpected cache behaviour with this list and > discuss about a solution. > > Indeed we are using cgit to provide a web interface to our internal user > and also to provide file to our reviewboard server. > > We are experiencing some cache issue on static pages when data are not > pushed yet to server but reviewboard tries to access these > files/repositories. Cache is adding even 404, 401 or 500 error for > static page, we can workaround this issue after reducing/setting static > cache issue but it looks not very useful to cache http errors. > > Do you think it is possible to only cache when HTTP is 200 OK? Other ideas? I don't think it will be easy to change the behaviour to cache only on 200 responses, and I'm not sure it's desirable to do so since the process of determining that a result is an error may involve significant work (e.g. loading packed refs or pack indexes). I can see an argument for changing the default for "cache-static-ttl" to a positive value, so that if we do cache an error result it will eventually time out without needing another page to be written into that cache slot, but I'm not sure I understand how you reviewboard server can access files that have not yet been pushed to the Git server. If you're reviewing committed changes, shouldn't the review be posted by a hook on the server, which would ensure that the commits are available before reviewboard knows about them?