Re: [PATCH] Fix crash when using path limit
On 24.11.2016 20:16, Lukas Fleischer wrote: > The array passed to setup_revisions() must be NULL-terminated. Fixes a > regression introduced in 455b598 (ui-patch.c: Use log_tree_commit() to > generate diffs, 2013-08-20). > > Reported-by: Florian Pritz > Signed-off-by: Lukas Fleischer Works perfectly. Thanks! signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Crash when using path limit in ui-patch.c
Hi, I get the following backtrace when trying to use the path limit feature while getting a patch. > #0 0x00467bb5 in prefix_pathspec (item=0x77ba48, > p_short_magic=0x7fffb2e8, raw=0x76e488, flags=0, prefix=0x0, prefixlen=0, > elt=0x3637353238343130 0x3637353238343130>) at pathspec.c:149 > #1 0x00468872 in parse_pathspec (pathspec=0x7fffc550, > magic_mask=0, flags=0, prefix=0x0, argv=0x76e480) at pathspec.c:418 > #2 0x00487efb in setup_revisions (argc=4, argv=0x7fffc430, > revs=0x7fffc500, opt=0x0) at revision.c:2253 > #3 0x004135eb in cgit_print_patch (new_rev=0x791670 > "03c580a9b31fb82187de3c882bc274441c41847d", old_rev=0x0, prefix=0x76dfd0 > "application/libraries") at ../ui-patch.c:88 > #4 0x00409534 in patch_fn () at ../cmd.c:119 > #5 0x00407281 in process_request () at ../cgit.c:744 > #6 0x00408d2b in cache_process (size=0, path=0x4fc87a > "/var/cache/cgit", key=0x777670 > "users/flo/filebin/patch/application/libraries?id=03c580a9b31fb82187de3c882bc274441c41847d", > ttl=-1, fn=0x407141 ) at ../cache.c:367 > #7 0x004083aa in cmd_main (argc=1, argv=0x7fffe048) at > ../cgit.c:1092 > #8 0x0041d40b in main (argc=1, argv=0x7fffe048) at > common-main.c:40 I'm not exactly sure what is going on, but I don't have the time to debug so I cobbled together a quick test case for this which you can view here: https://paste.xinu.at/vgCm/ The test "works" before commit 5fe88a9c81517b1a8a93d930c738cbb6f71dec2a since that introduces the feature and using the path limit doesn't actually change the output. It's just a quick reproducer. Florian signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH v2] Support Git over HTTP using git-http-backend
On 29.12.2014 18:16, Lukas Fleischer wrote: > On Mon, 29 Dec 2014 at 17:56:05, Florian Pritz wrote: >> This saves users from the hassle of setting up git-http-backend when >> they already run cgit. >> >> References: man git-http-backend Since this has not yet been merged and it currently conflicts with master: Is there any interest in the patch? If yes, I'd be happy to resolve the conflict. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH v2] Support Git over HTTP using git-http-backend
This saves users from the hassle of setting up git-http-backend when
they already run cgit.
References: man git-http-backend
Signed-off-by: Florian Pritz
---
v2:
- git_root allocation was too small by 1
- change comment style to c89
cgit.c | 3 +++
cgit.h | 1 +
cgitrc.5.txt | 8
cmd.c| 12
ui-clone.c | 61
ui-clone.h | 2 ++
6 files changed, 87 insertions(+)
diff --git a/cgit.c b/cgit.c
index 79019c2..0c4a292 100644
--- a/cgit.c
+++ b/cgit.c
@@ -124,6 +124,8 @@ static void config_cb(const char *name, const char *value)
ctx.cfg.head_include = xstrdup(value);
else if (!strcmp(name, "header"))
ctx.cfg.header = xstrdup(value);
+ else if (!strcmp(name, "http-backend-path"))
+ ctx.cfg.http_backend_path = xstrdup(value);
else if (!strcmp(name, "logo"))
ctx.cfg.logo = xstrdup(value);
else if (!strcmp(name, "index-header"))
@@ -353,6 +355,7 @@ static void prepare_context(void)
ctx.cfg.css = "/cgit.css";
ctx.cfg.logo = "/cgit.png";
ctx.cfg.favicon = "/favicon.ico";
+ ctx.cfg.http_backend_path = NULL;
ctx.cfg.local_time = 0;
ctx.cfg.enable_http_clone = 1;
ctx.cfg.enable_index_owner = 1;
diff --git a/cgit.h b/cgit.h
index 42140ac..dcd44f0 100644
--- a/cgit.h
+++ b/cgit.h
@@ -190,6 +190,7 @@ struct cgit_config {
char *footer;
char *head_include;
char *header;
+ char *http_backend_path;
char *index_header;
char *index_info;
char *logo;
diff --git a/cgitrc.5.txt b/cgitrc.5.txt
index be6703f..62b73ba 100644
--- a/cgitrc.5.txt
+++ b/cgitrc.5.txt
@@ -218,6 +218,11 @@ header::
The content of the file specified with this option will be included
verbatim at the top of all pages. Default value: none.
+http-backend-path::
+ Path to the git-http-backend smart HTTP backend binary. Setting this
+ allows the git clone to fetch/push via Git over HTTP. You'll also
+ need to enable enable-http-clone for this to work. Default value: none.
+
include::
Name of a configfile to include before the rest of the current config-
file is parsed. Default value: none. See also: "MACRO EXPANSION".
@@ -766,6 +771,9 @@ enable-index-owner=1
# Allow http transport git clone
enable-http-clone=1
+# Use Git over HTTP
+http-backend-path=/usr/lib/git-core/git-http-backend
+
# Show extra links for each repository on the index page
enable-index-links=1
diff --git a/cmd.c b/cmd.c
index 188cd56..889ed05 100644
--- a/cmd.c
+++ b/cmd.c
@@ -136,6 +136,16 @@ static void tree_fn(void)
cgit_print_tree(ctx.qry.sha1, ctx.qry.path);
}
+static void git_upload_pack_fn(void)
+{
+ cgit_clone_git_upload_pack();
+}
+
+static void git_receive_pack_fn(void)
+{
+ cgit_clone_git_receive_pack();
+}
+
#define def_cmd(name, want_repo, want_layout, want_vpath, is_clone) \
{#name, name##_fn, want_repo, want_layout, want_vpath, is_clone}
@@ -162,6 +172,8 @@ struct cgit_cmd *cgit_get_cmd(void)
def_cmd(summary, 1, 1, 0, 0),
def_cmd(tag, 1, 1, 0, 0),
def_cmd(tree, 1, 1, 1, 0),
+ {"git-upload-pack", git_upload_pack_fn, 1, 0, 0, 1},
+ {"git-receive-pack", git_receive_pack_fn, 1, 0, 0, 1},
};
int i;
diff --git a/ui-clone.c b/ui-clone.c
index a4ffd6e..91d8306 100644
--- a/ui-clone.c
+++ b/ui-clone.c
@@ -69,8 +69,43 @@ static void send_file(char *path)
html_include(path);
}
+static void dispatch_to_git_http_backend(void)
+{
+ if (access(ctx.cfg.http_backend_path, X_OK) != -1) {
+ size_t git_root_len;
+ char *git_root = NULL;
+
+ /* git-http-backend does it's own URL parsing and concatenates
+* GIT_PROJECT_ROOT and PATH_INFO to find the git repo.
+* The root is the same as scan-path, but scan-path is not
+* always available so we calculate the root path.
+* Example:
+* repo.path = /srv/git/some/more/dirs/
+* qry.repo= some/more/dirs
+* -> git_root = /srv/git/
+*/
+ strip_suffix(ctx.repo->path, "/", &git_root_len);
+ strip_suffix_mem(ctx.repo->path, &git_root_len, ctx.qry.repo);
+
+ git_root = xmalloc(git_root_len + 1);
+ strncpy(git_root, ctx.repo->path, git_root_len);
+ git_root[git_root_len] = '\0';
+
+ setenv("GIT_PROJECT_ROOT", git_root, 1);
+ execl(ctx.cfg.http_backend_path, "git-http-backend", NULL);
+
[PATCH] Support Git over HTTP using git-http-backend
This saves users from the hassle of setting up git-http-backend when
they already run cgit.
References: man git-http-backend
Signed-off-by: Florian Pritz
---
I've messed up updating my master branch and used git-send-email on it. You
might have gotten 1 or 2 patches that are already applied because of that.
Sorry.
cgit.c | 3 +++
cgit.h | 1 +
cgitrc.5.txt | 8
cmd.c| 12
ui-clone.c | 60
ui-clone.h | 2 ++
6 files changed, 86 insertions(+)
diff --git a/cgit.c b/cgit.c
index 79019c2..0c4a292 100644
--- a/cgit.c
+++ b/cgit.c
@@ -124,6 +124,8 @@ static void config_cb(const char *name, const char *value)
ctx.cfg.head_include = xstrdup(value);
else if (!strcmp(name, "header"))
ctx.cfg.header = xstrdup(value);
+ else if (!strcmp(name, "http-backend-path"))
+ ctx.cfg.http_backend_path = xstrdup(value);
else if (!strcmp(name, "logo"))
ctx.cfg.logo = xstrdup(value);
else if (!strcmp(name, "index-header"))
@@ -353,6 +355,7 @@ static void prepare_context(void)
ctx.cfg.css = "/cgit.css";
ctx.cfg.logo = "/cgit.png";
ctx.cfg.favicon = "/favicon.ico";
+ ctx.cfg.http_backend_path = NULL;
ctx.cfg.local_time = 0;
ctx.cfg.enable_http_clone = 1;
ctx.cfg.enable_index_owner = 1;
diff --git a/cgit.h b/cgit.h
index 42140ac..dcd44f0 100644
--- a/cgit.h
+++ b/cgit.h
@@ -190,6 +190,7 @@ struct cgit_config {
char *footer;
char *head_include;
char *header;
+ char *http_backend_path;
char *index_header;
char *index_info;
char *logo;
diff --git a/cgitrc.5.txt b/cgitrc.5.txt
index be6703f..62b73ba 100644
--- a/cgitrc.5.txt
+++ b/cgitrc.5.txt
@@ -218,6 +218,11 @@ header::
The content of the file specified with this option will be included
verbatim at the top of all pages. Default value: none.
+http-backend-path::
+ Path to the git-http-backend smart HTTP backend binary. Setting this
+ allows the git clone to fetch/push via Git over HTTP. You'll also
+ need to enable enable-http-clone for this to work. Default value: none.
+
include::
Name of a configfile to include before the rest of the current config-
file is parsed. Default value: none. See also: "MACRO EXPANSION".
@@ -766,6 +771,9 @@ enable-index-owner=1
# Allow http transport git clone
enable-http-clone=1
+# Use Git over HTTP
+http-backend-path=/usr/lib/git-core/git-http-backend
+
# Show extra links for each repository on the index page
enable-index-links=1
diff --git a/cmd.c b/cmd.c
index 188cd56..889ed05 100644
--- a/cmd.c
+++ b/cmd.c
@@ -136,6 +136,16 @@ static void tree_fn(void)
cgit_print_tree(ctx.qry.sha1, ctx.qry.path);
}
+static void git_upload_pack_fn(void)
+{
+ cgit_clone_git_upload_pack();
+}
+
+static void git_receive_pack_fn(void)
+{
+ cgit_clone_git_receive_pack();
+}
+
#define def_cmd(name, want_repo, want_layout, want_vpath, is_clone) \
{#name, name##_fn, want_repo, want_layout, want_vpath, is_clone}
@@ -162,6 +172,8 @@ struct cgit_cmd *cgit_get_cmd(void)
def_cmd(summary, 1, 1, 0, 0),
def_cmd(tag, 1, 1, 0, 0),
def_cmd(tree, 1, 1, 1, 0),
+ {"git-upload-pack", git_upload_pack_fn, 1, 0, 0, 1},
+ {"git-receive-pack", git_receive_pack_fn, 1, 0, 0, 1},
};
int i;
diff --git a/ui-clone.c b/ui-clone.c
index a4ffd6e..15bd78b 100644
--- a/ui-clone.c
+++ b/ui-clone.c
@@ -69,8 +69,42 @@ static void send_file(char *path)
html_include(path);
}
+static void dispatch_to_git_http_backend(void)
+{
+ if (access(ctx.cfg.http_backend_path, X_OK) != -1) {
+ size_t git_root_len;
+ char *git_root = NULL;
+
+ // git-http-backend does it's own URL parsing and concatenates
+ // GIT_PROJECT_ROOT and PATH_INFO to find the git repo.
+ // The root is the same as scan-path, but scan-path is not
+ // always available so we calculate the root path.
+ // Example:
+ // repo.path = /srv/git/some/more/dirs/
+ // qry.repo= some/more/dirs
+ // -> git_root = /srv/git/
+ strip_suffix(ctx.repo->path, "/", &git_root_len);
+ strip_suffix_mem(ctx.repo->path, &git_root_len, ctx.qry.repo);
+
+ git_root = xmalloc(git_root_len);
+ strncpy(git_root, ctx.repo->path, git_root_len);
+ git_root[git_root_len] = '\0';
+
+ setenv("GIT_PROJECT_ROOT", git_root, 1);
+
Re: adopting kernel.org's css modifications?
On 20.02.2014 21:27, Lukas Fleischer wrote:
> On Thu, 20 Feb 2014 at 20:23:56, Jason A. Donenfeld wrote:
>> Looks like kernel.org makes some changes. Do we want to adopt any of
>> these? Some of them are pretty, like the even/odd background. Others
>> I'm not sure what they do...
>> [...]
>
> On the even/odd background (didn't check the other changes): I think
> that one looks good when having a lot of repositories and doesn't look
> good when having only a few of them. I also think that it is a bit weird
> that the "Clone" row is sometimes highlighted
Just override the background colour for like so:
div#cgit table.list tr:nth-child(odd),
div#cgit table.list th {
background: white;
}
Apart from that I'm not sure if striping adds much value given table
lines have a different background on hover already.
I didn't look at the other changes.
signature.asc
Description: OpenPGP digital signature
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH 06/12] filter: add preliminary lua support
On 13.01.2014 05:11, Jason A. Donenfeld wrote: > Signed-off-by: Jason A. Donenfeld > --- > cgit.h | 2 +- > cgit.mk | 13 ++- > filter.c | 284 > --- All those *_lua_filter functions look rather self contained, maybe they should be split into filter_lua.c for readability? Also I'm not sure why documenting the filter and adding error reporting to totally new code go into separate commits. They are one logical change after all. As Lukas already said it's probably a lot better if you split the cleanup and moving-stuff-around into it's own patch. (Or merge it into "basic write hooking infrastructure" since you create that code there so it should be created at the correct place) signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On 10.01.2014 21:36, John Keeping wrote: >> Looks rather easy to slurp stdin (from http://www.lua.org/pil/21.1.html): > > Interesting. But I think it will be simpler from both side if the > interface is just a function call source_filter could potentially get a rather long input and might not need it all at once. If it can processes input line by line or similar it makes sense to support that by writing chunks rather than buffering everything. I believe we currently already buffer the file (ui-tree.c print_object() buf variable) before calling the source_filter, but keeping the possibility to change that later is good. Also slurping is not really that much harder than writing the function header so I don't see a benefit in adding buffering to the cgit code. Last but not least, it keeps the interface between "exec" and "lua" filters the same or at least rather similar. If you can call a lua script as if it was execed (setting argv) that would make the handler totally transparent, but faster. > The only thing I'm not sure about is how the specification of the filter > function works, given that I don't think we can call a complete Lua > script as a function. (I'm also assuming that the Lua script will be in > an external file and not stored inline in the CGit config). http://www.lua.org/pil/25.2.html signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On 10.01.2014 21:11, John Keeping wrote:
> Forking and using Lua in the child is an interesting idea.
>
> I need to investigate how Lua generally deals with I/O, but it feels
> like it will be simpler to use a simple function interface than deal
> with slurping in the input in Lua.
Looks rather easy to slurp stdin (from http://www.lua.org/pil/21.1.html):
> t = io.read("*all") -- read the whole file
> t = string.gsub(t, ...) -- do the job
> io.write(t) -- write the file
signature.asc
Description: OpenPGP digital signature
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On 10.01.2014 18:57, Jason A. Donenfeld wrote: > On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote: >> >> Isn't this (fast scripting with lots of features) when people normally >> start using lua? >> > > This would have the same challenges as using .so files, w.r.t. hooking > write() (or the html functions), but would be very interesting indeed, > because Lua... How about using the current fork approach but instead of calling execvp use lua. I believe forks are pretty cheap on linux, it's the exec that's costly. If we do it like that we could reuse stdin/stdout, we could pass arguments via lua tables (like command line arguments now), but we should have little overhead for the script loading/executing. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On 10.01.2014 16:57, Jason A. Donenfeld wrote: > On Fri, Jan 10, 2014 at 10:06 AM, John Keeping wrote: >> >> This seems drastically over complicated. > > So here's the situation. There's a lot of "state" that we're taking > advantage of in using processes that terminate, that needs to be > replicated: Isn't this (fast scripting with lots of features) when people normally start using lua? Having said that, I haven't used lua yet so don't expect any code from me, but this example [1] looks rather simple. [1]: http://lua-users.org/wiki/SimpleLuaApiExample signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [RFC] Relocate repos when using scan-path
On 18.05.2013 18:06, John Keeping wrote: > On Sat, May 18, 2013 at 05:46:35PM +0200, Jason A. Donenfeld wrote: >> On Sat, May 18, 2013 at 5:27 PM, Florian Pritz wrote: >> > The point is that I want to keep already cloned repositories (as in "git >> > clone git://foo" via git-daemon) working and mod_rewrite won't help with >> > that even though it would probably work fine with the http clones. >> >> Make a directory elsewhere on the file system. >> Symlink everything you need into it. >> Point git-daemon at that. > > Subject: [PATCH] Add scan-exclude option to filter out repositories That's a global option and I don't want to update the global config each time I add/move repos. Maybe we could check if the repo dir is a symlink and only hide it and redirect to the new location if the last target is within scan-path? That would allow users to easily move repos to subdirectories while still allowing them to get the current behaviour back by simply moving the target somewhere outside scan-path and placing some symlinks. It also won't need a option if documented properly and IMHO it's rather intuitive. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [RFC] Relocate repos when using scan-path
On 18.05.2013 17:10, John Keeping wrote: > On Mon, May 13, 2013 at 03:56:13PM +0200, Florian Pritz wrote: >> Having now seen section-from-path now I think this feature is pretty >> useful, but to fully utilize it I'd have to move around some repos for a >> proper directory structure. >> >> Since I want to keep URLs working for existing clones I thought about >> placing symlinks in the old location, but then cgit will display each >> repo twice. >> >> Should there be an option to ignore symlinks, a (per repo) list of valid >> paths for the index or something else to keep cgit's index list clean? > > I think what you want here is to return a "301 Moved Permanently" > response on the old URLs. I considered adding this to CGit but I'm not > sure we should add yet more configuration options when this can already > be achieved with mod_rewrite or ngx_http_rewrite_module. > The point is that I want to keep already cloned repositories (as in "git clone git://foo" via git-daemon) working and mod_rewrite won't help with that even though it would probably work fine with the http clones. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
[RFC] Relocate repos when using scan-path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Having now seen section-from-path now I think this feature is pretty useful, but to fully utilize it I'd have to move around some repos for a proper directory structure. Since I want to keep URLs working for existing clones I thought about placing symlinks in the old location, but then cgit will display each repo twice. Should there be an option to ignore symlinks, a (per repo) list of valid paths for the index or something else to keep cgit's index list clean? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJRkPD9AAoJEG0WVcFM4cE+V3EP+gNrdR0mxRGrDSbqiiCBJuHR J/zXz2RCKDT29ZzvI94aCWilxJgYYcNKMt+RuQW88PyKLDhZrx9FDNg2WPARMI7N QCxj/J/OkXem4lzcpvZFFMjmpOMKqD3k3CWFCayjqpNn7Ubtlfyy6gB81x2iMR0U G1TrxGIC9k15qoXDwlaAk6NdpN3p/LWECDaTtANFO9uEeaI9EeUj2OE4N0blrMve hXu9i6e4qP+WYuDEfWUz9JAeJ6aBEUWBxv0nk5zR/wL3mVa3x0mFcrDVabn4V1aG wPf1PgucxAhce6GeF+iAOKrkmQSmffybmgdUVSAb+t7PFcDCGJKflOeIiZLPlHPj DK3jzRxXEfsTr2GiJAbCEEhQds80Hs3WQB6QwTvOyi0bWlcOcA4+E29Ri6lwZOxn EF0Wwh3MFeCgS5YdS+pGTsKHhdCNkkBZ95BTw334EnhQuWWmhl0fyNqQFUK4ohRO Tv4mxp2eql2Kg9gQv17rLbmJ+EYAIgHYEI9lvcQGAI2fiQQIJ4bXVGkOs/mCk6BV M053OdcKvQNJ4IRgqJxEhSlQf6C3MCnh85QXeUK0fpYXuYtakclmdNIWE/ytmE2H Fs/z+I3qFwXQ5QNGG41Anq8daFVzAPRETMO9UMcAC2IvtKUib2Ma16olTTx4C5xD hZKLPDtcFUHSIpzqpBBj =1SjG -END PGP SIGNATURE- ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
