[PATCH] extra-head-content: introduce another option for meta tags

[Jason A. Donenfeld]

This is to support things like go-import meta tags, which are on a
per-repo basis.

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>
---
This is kind of really ugly, and I'm not keen on its approach, but I
thought I'd post it to get some feedback on the general "requirement".
It turns out, the ugly Go ecosystem requires meta tags like these to
function:

https://git.zx2c4.com/terrible-go-package; />

The question is: is cgit a good place for doing this? Is this here,
below, actually a good way of going about it, if so?

 cgit.c   | 4 
 cgit.h   | 1 +
 cgitrc.5.txt | 4 
 shared.c | 1 +
 ui-shared.c  | 2 ++
 5 files changed, 12 insertions(+)

diff --git a/cgit.c b/cgit.c
index bd9cb3f..cf65bbd 100644
--- a/cgit.c
+++ b/cgit.c
@@ -46,6 +46,8 @@ static void repo_config(struct cgit_repo *repo, const char 
*name, const char *va
repo->homepage = xstrdup(value);
else if (!strcmp(name, "defbranch"))
repo->defbranch = xstrdup(value);
+   else if (!strcmp(name, "extra-head-content"))
+   repo->extra_head_content = xstrdup(value);
else if (!strcmp(name, "snapshots"))
repo->snapshots = ctx.cfg.snapshots & 
cgit_parse_snapshots_mask(value);
else if (!strcmp(name, "enable-commit-graph"))
@@ -802,6 +804,8 @@ static void print_repo(FILE *f, struct cgit_repo *repo)
}
if (repo->defbranch)
fprintf(f, "repo.defbranch=%s\n", repo->defbranch);
+   if (repo->extra_head_content)
+   fprintf(f, "repo.extra-head-content=%s\n", 
repo->extra_head_content);
if (repo->module_link)
fprintf(f, "repo.module-link=%s\n", repo->module_link);
if (repo->section)
diff --git a/cgit.h b/cgit.h
index 005ae63..edec271 100644
--- a/cgit.h
+++ b/cgit.h
@@ -79,6 +79,7 @@ struct cgit_repo {
char *name;
char *path;
char *desc;
+   char *extra_head_content;
char *owner;
char *homepage;
char *defbranch;
diff --git a/cgitrc.5.txt b/cgitrc.5.txt
index 4da166c..fa2fbfc 100644
--- a/cgitrc.5.txt
+++ b/cgitrc.5.txt
@@ -501,6 +501,10 @@ repo.defbranch::
 repo.desc::
The value to show as repository description. Default value: none.
 
+repo.extra-head-content::
+   This value will be added verbatim to the head section of each page
+   displayed for this repo. Default value: none.
+
 repo.homepage::
The value to show as repository homepage. Default value: none.
 
diff --git a/shared.c b/shared.c
index 21ac8f4..d0405cf 100644
--- a/shared.c
+++ b/shared.c
@@ -53,6 +53,7 @@ struct cgit_repo *cgit_add_repo(const char *url)
ret->name = ret->url;
ret->path = NULL;
ret->desc = cgit_default_repo_desc;
+   ret->extra_head_content = NULL;
ret->owner = NULL;
ret->homepage = NULL;
ret->section = ctx.cfg.section;
diff --git a/ui-shared.c b/ui-shared.c
index 9d8f66b..5197cd6 100644
--- a/ui-shared.c
+++ b/ui-shared.c
@@ -766,6 +766,8 @@ void cgit_print_docstart(void)
cgit_add_clone_urls(print_rel_vcs_link);
if (ctx.cfg.head_include)
html_include(ctx.cfg.head_include);
+   if (ctx.repo && ctx.repo->extra_head_content)
+   html(ctx.repo->extra_head_content);
html("\n");
html("\n");
if (ctx.cfg.header)
-- 
2.16.1

___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 0/4] Add ui-blame syntax highlighting

[Jason A. Donenfeld]

This patchset has been merged to master. Thanks for your contribution!

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.16.0

[Jason A. Donenfeld]

Thanks, merged this.

I grabbed the commit from this email, rather than from your branch in
the repo, because this one had the signed-off-by line and the other
didn't.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 4/4 v3] ui-blame: Allow syntax highlighting

[Jason A. Donenfeld]

Works remarkably well. Excellent work. Example, for others on the list:

https://git.zx2c4.com/WireGuard/blame/src/noise.c

Pending objections from others, I'll merge this from jd/color-blame to
master in a few days.

Thanks for this series!

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 4/4] ui-blame: Allow syntax highlighting

[Jason A. Donenfeld]

Just waiting on resubmission of this 4/4, then. I'll put 1-3 in a branch.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 0/4] adding color to ui-blame

[Jason A. Donenfeld]

Hi Jeff,

Oh, cool. What's your idea for accomplishing that? Planning on putting
it through the filter, buffering it, and then spitting it back out in
equal sized chunks, hoping the filter doesn't add extra new lines?

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 0/4] adding color to ui-blame

[Jason A. Donenfeld]

Right, we may very well need a more capable model.

One approach would be to get rid of all the exec stuff, and instead
have plugins, that can register themselves in all sorts of places. A
plugin would define a series of hooks and filters, which would be
directly called at the right time. We'd expand the Lua stuff to
support that, and then add Python support and all the other various
languages one at a time.

Would indeed be a big project, but potentially useful.

Though I _do_ like the simplicity of the current situation quite a bit.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Spelling fixes

[Jason A. Donenfeld]

Applied thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

[PATCH 0/4] adding color to ui-blame

[Jason A. Donenfeld]

This patch set is currently broken, because in the exec filter,
processes like to buffer their output. The result is that the text winds
up at the bottom:

https://git.zx2c4.com/cgit/blame/cache.c

If anybody has some ideas on how we might enact a flush operation, please
pipe up (hah).

Jason A. Donenfeld (4):
  filter: add generic scafolding for temporarily disabling filter
  filter: wire up exec_filter to enable function
  filter: wire up lua_filter to enable function
  ui-blame: put source lines through filter

 cgit.h |  3 +++
 filter.c   | 46 ++
 ui-blame.c | 15 ++-
 3 files changed, 55 insertions(+), 9 deletions(-)

-- 
2.14.2

___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

[PATCH 2/4] filter: wire up exec_filter to enable function

[Jason A. Donenfeld]

We also move pipe_fh to be local, since it's not needed any place else.

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>
---
 cgit.h   |  1 +
 filter.c | 27 +--
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/cgit.h b/cgit.h
index 8da69e7..f9949a7 100644
--- a/cgit.h
+++ b/cgit.h
@@ -72,6 +72,7 @@ struct cgit_exec_filter {
char *cmd;
char **argv;
int old_stdout;
+   int new_stdout;
int pid;
 };
 
diff --git a/filter.c b/filter.c
index aa0027a..4deb4de 100644
--- a/filter.c
+++ b/filter.c
@@ -60,9 +60,8 @@ static int open_exec_filter(struct cgit_filter *base, va_list 
ap)
die_errno("Unable to exec subprocess %s", filter->cmd);
}
close(pipe_fh[0]);
-   chk_non_negative(dup2(pipe_fh[1], STDOUT_FILENO),
-   "Unable to use pipe as STDOUT");
-   close(pipe_fh[1]);
+   filter->new_stdout = pipe_fh[1];
+   chk_non_negative(dup2(filter->new_stdout, STDOUT_FILENO), "Unable to 
assign new fd to STDOUT");
return 0;
 }
 
@@ -71,9 +70,10 @@ static int close_exec_filter(struct cgit_filter *base)
struct cgit_exec_filter *filter = (struct cgit_exec_filter *)base;
int i, exit_status = 0;
 
-   chk_non_negative(dup2(filter->old_stdout, STDOUT_FILENO),
-   "Unable to restore STDOUT");
+   chk_non_negative(dup2(filter->old_stdout, STDOUT_FILENO), "Unable to 
assign old fd to STDOUT");
close(filter->old_stdout);
+   close(filter->new_stdout);
+
if (filter->pid < 0)
goto done;
waitpid(filter->pid, _status, 0);
@@ -82,10 +82,24 @@ static int close_exec_filter(struct cgit_filter *base)
die("Subprocess %s exited abnormally", filter->cmd);
 
 done:
+   close(filter->old_stdout);
+   close(filter->new_stdout);
for (i = 0; i < filter->base.argument_count; i++)
filter->argv[i + 1] = NULL;
-   return WEXITSTATUS(exit_status);
+   return WIFEXITED(exit_status);
+}
 
+static int enable_exec_filter(struct cgit_filter *base, bool on)
+{
+   struct cgit_exec_filter *filter = (struct cgit_exec_filter *)base;
+   int ret;
+
+   if (on)
+   ret = dup2(filter->new_stdout, STDOUT_FILENO);
+   else
+   ret = dup2(filter->old_stdout, STDOUT_FILENO);
+   chk_non_negative(ret, "Unable to assign fd to STDOUT");
+   return 0;
 }
 
 static void fprintf_exec_filter(struct cgit_filter *base, FILE *f, const char 
*prefix)
@@ -128,6 +142,7 @@ void cgit_exec_filter_init(struct cgit_exec_filter *filter, 
char *cmd, char **ar
memset(filter, 0, sizeof(*filter));
filter->base.open = open_exec_filter;
filter->base.close = close_exec_filter;
+   filter->base.enable = enable_exec_filter;
filter->base.fprintf = fprintf_exec_filter;
filter->base.cleanup = cleanup_exec_filter;
filter->cmd = cmd;
-- 
2.14.2

___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

[PATCH 3/4] filter: wire up lua_filter to enable function

[Jason A. Donenfeld]

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>
---
 filter.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/filter.c b/filter.c
index 4deb4de..7b5bef5 100644
--- a/filter.c
+++ b/filter.c
@@ -353,6 +353,15 @@ static int close_lua_filter(struct cgit_filter *base)
return ret;
 }
 
+static int enable_lua_filter(struct cgit_filter *base, bool on)
+{
+   if (on)
+   hook_write(base, write_lua_filter);
+   else
+   unhook_write();
+   return 0;
+}
+
 static void fprintf_lua_filter(struct cgit_filter *base, FILE *f, const char 
*prefix)
 {
struct lua_filter *filter = (struct lua_filter *)base;
@@ -368,6 +377,7 @@ static struct cgit_filter *new_lua_filter(const char *cmd, 
int argument_count)
memset(filter, 0, sizeof(*filter));
filter->base.open = open_lua_filter;
filter->base.close = close_lua_filter;
+   filter->base.enable = enable_lua_filter;
filter->base.fprintf = fprintf_lua_filter;
filter->base.cleanup = cleanup_lua_filter;
filter->base.argument_count = argument_count;
-- 
2.14.2

___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

[PATCH 4/4] ui-blame: put source lines through filter

[Jason A. Donenfeld]

We toggle the filter on and off so that the control table can avoid
going through the filter.

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>
---
 ui-blame.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/ui-blame.c b/ui-blame.c
index 62cf431..71aec65 100644
--- a/ui-blame.c
+++ b/ui-blame.c
@@ -70,7 +70,12 @@ static void emit_blame_entry(struct blame_scoreboard *sb,
cpend = blame_nth_line(sb, ent->lno + ent->num_lines);
 
html("");
-   html_ntxt(cp, cpend - cp);
+   if (ctx.repo->source_filter) {
+   cgit_enable_filter(ctx.repo->source_filter, true);
+   html_raw(cp, cpend - cp);
+   cgit_enable_filter(ctx.repo->source_filter, false);
+   } else
+   html_ntxt(cp, cpend - cp);
html("\n");
 }
 
@@ -90,6 +95,7 @@ static void print_object(const unsigned char *sha1, const 
char *path,
struct blame_scoreboard sb;
struct blame_origin *o;
struct blame_entry *ent = NULL;
+   char *filter_arg;
 
type = sha1_object_info(sha1, );
if (type == OBJ_BAD) {
@@ -131,6 +137,11 @@ static void print_object(const unsigned char *sha1, const 
char *path,
return;
}
 
+   if (ctx.repo->source_filter) {
+   filter_arg = xstrdup(path);
+   cgit_open_filter(ctx.repo->source_filter, filter_arg);
+   cgit_enable_filter(ctx.repo->source_filter, false);
+   }
html("");
for (ent = sb.ent; ent; ) {
struct blame_entry *e = ent->next;
@@ -139,6 +150,8 @@ static void print_object(const unsigned char *sha1, const 
char *path,
ent = e;
}
html("\n");
+   if (ctx.repo->source_filter)
+   cgit_close_filter(ctx.repo->source_filter);
free((void *)sb.final_buf);
 
cgit_print_layout_end();
-- 
2.14.2

___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] parsing: don't clear existing state with empty input

[Jason A. Donenfeld]

Looks reasonable to me. Thanks for reporting, Tom, and thanks for the
patch John. Applied.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 0/5] Add ui-blame

[Jason A. Donenfeld]

Merged to master. Working quite nicely:

https://git.zx2c4.com/cgit/blame/ui-shared.c

Jeff -- do we want to be passing this through the source code filter
to get highlighted lines?
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v2] Use https for submodule

[Jason A. Donenfeld]

Merged, thanks!
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-repolist: remove unused variable

[Jason A. Donenfeld]

On Wed, Jul 26, 2017 at 8:34 PM, Christian Hesse  wrote:
>> Jason, any chance you can go through our for-jason branches and merge
>> them anytime soon?
>
> Yes, please!

Absolutely. I'm finishing up a time consuming job this week, and
mid-next week, I'll start merging.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] cache: flush stdio before restoring FDs

[Jason A. Donenfeld]

Hey John,

Wow, that was quick. Konstantin and I were just talking about this.
I'll review this and merge things asap.

Another related thing were were discussing and I was just
investigating is the inherent buffering that our cache system uses.
When it's filling a slot, everything is buffered until the end, when
the slot is printed. This doesn't work well for huge tars, which might
buffer for more than an HTTP timeout. I'm looking into calling fork()
before slot->fn() and then calling splice in the parent...

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: Blame

[Jason A. Donenfeld]

Hey Jeff,

If option 1 can be done cleanly enough, that'd be fine with me.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Remove unused variable from sort_section()

[Jason A. Donenfeld]

Looks good to me.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] filter: set environment variable PYTHONIOENCODING to utf-8

[Jason A. Donenfeld]

On Sun, Mar 12, 2017 at 6:51 PM, John Keeping  wrote:
> While I'm inclined to agree with this, in this particular case we
> explicitly encode pages as UTF-8 so there is an argument that we should
> be telling child processes that UTF-8 is the correct encoding.

That's a compelling argument, actually.

>
> Maybe we should be looking to change LANG instead, but I'm not sure how
> reliably we can do that.

I'm more onboard with that. Does changing LANG influence the PYTHON
variable implicitly?

> Is it safe to do something like:
>
> const char *lang = getenv("LANG");
> struct strbuf sb = STRBUF_INIT;
>
> if (!lang)
> lang = "C";
> strbuf_addf(, "%.*s.UTF-8",
> (int) (strchrnul(lang, '.') - lang), lang);
> setenv("LANG", sb.buf);

That's probably not too bad, though I wonder if we could get away with
just explicitly setting a more generic UTF-8 instead of trying to read
the user's language preferences.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] filter: set environment variable PYTHONIOENCODING to utf-8

[Jason A. Donenfeld]

Hey guys,

Sorry for the delay. I'm currently on the road traveling and won't be
properly back at my desk until the end of next week.

However, my initial reaction is that hard coding various
interpreter-specific environment variables in cgit itself is not
correct, and that this is something better left to the CGI environment
as it sees fit. However, we may benefit from explicit script level
configuration of unicode stuff.

I'll revisit this next week.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/3] filter: introduce cgit_open_email_filter() wrapper

[Jason A. Donenfeld]

Can you resubmit this series as a normal git-send-email situation?
Very hard to review as attachments like this.

Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 0/3] Fix segfault found by AFL

[Jason A. Donenfeld]

Excellent. Running AFL on cgit is a great idea. I'll merge and review when
I'm back at my desk on Tuesday.

On Feb 19, 2017 12:45, "John Keeping"  wrote:

I set AFL [0] loose on CGit's URL input yesterday and it managed to find
one issue that leads to a segfault via a null dereference.

Either of the first or third patches fixes the segfault, but I much
prefer the first as a solid fix, the third is a bit too subtle as a way
to ensure that the necessary invariant holds.

The second patch also fixes the route that AFL found, but it's possible
to get the same effect using broken out query parameters like
"?p=log=foo" but I'm including it because it seems to make sense to
use the value of the final "url" parameter we receive fully rather than
some combination of that and a previous URL.

[0] http://lcamtuf.coredump.cx/afl/

John Keeping (3):
  ui-shared: don't print path crumbs without a repo
  parsing: clear query path before starting
  cgit: don't set vpath unless repo is set

 cgit.c  | 12 ++--
 parsing.c   |  2 +-
 ui-shared.c |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

--
2.12.0.rc2.230.ga28edc07cd

___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: patch links do not have stable checksums

[Jason A. Donenfeld]

Seems most reasonable to simply keep it something static and not add a nob.

However, John - you raise a good point. Git's diff feature isn't
exactly stable itself, with all sorts of interesting new diffing
strategies being tried out in newer versions. So perhaps this isn't
really an feasible goal in the first place...
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PULL] Fix escaping in atom output

[Jason A. Donenfeld]

Thanks. I'll review and merge.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] ui-patch: fix segfault when a path prefix is passed

[Jason A. Donenfeld]

Nice catch, thanks.

Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.11.0

[Jason A. Donenfeld]

Thanks for the reminder. Merged!
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.11.0

[Jason A. Donenfeld]

Looks fine to me. Queue it up.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Link with -ldl on GNU Hurd

[Jason A. Donenfeld]

Hurd!

Honored to merge this.
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Fix crash when using path limit

[Jason A. Donenfeld]

Hi Lukas,

Seems fine to me. Queue it up.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [ANNOUNCE] CGIT v1.1 Released

[Jason A. Donenfeld]

Jeeze louise, nice catch. Thanks. Merged.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v5 1/1] ui-shared: allow to split the repository link

[Jason A. Donenfeld]

On Thu, Nov 24, 2016 at 6:32 PM, Petr Vorel  wrote:
> Any idea how to cope with it? I thought to use this feature only if repo.name 
> and repo.url
> are the same.

One way might be to always use the `name` part and not the `url`, but
to ensure that any clickable links are actually useful. Namely, ensure
that any clickable links go to subtrees that contain other
repositories. This would also help collapse single-child directories,
like what we now do in tree view.

@John - any opinions on this?

>> I realize that John asked for a config variable in v3. But I do wonder
>> if this really is so necessary. In what case would somebody _not_ want
>> this behavior?
> I don't think so, I'd also remove the config variable.

I'll defer to John, then, to defend having a config variable.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

[ANNOUNCE] CGIT v1.1 Released

[Jason A. Donenfeld]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

CGit 1.1 is now available. This is mainly a bug fix and stability release, but
there are a few nice new features this release too. This release cycle has
also seen an improvement in contribution workflow. Several cgit core
developers now share the task of integrating user contributions, which we hope
will decrease submit-to-review-to-merge latency.

== CGit on the Web ==

* homepage: https://git.zx2c4.com/cgit/about/
* git repository: https://git.zx2c4.com/cgit/
* git clone: git://git.zx2c4.com/cgit
* mailing list: cgit@lists.zx2c4.com
* mailing list subscribe: https://lists.zx2c4.com/mailman/listinfo/cgit

== ChangeLog v1.1 ==

30 files changed, 389 insertions(+), 319 deletions(-)

Notable Changes:

* Single-child trees are now elided into single links. Instead of having to
  click through depths of links, now a single link will to to the maximum
  point of depth.

* Continuing our commitment to supporting kernel.org, we've adopted some of
  their style changes in our CSS, now allowing for colored even/odd table rows
  with a nice hover effect.

* Snapshot name prettification is now consistent, so that the 'v' prefix
  stripping only occurs when it won't create any collisions. This is a slight
  change of behavior, but I imagine cases of folks relying on the old broken
  behavior are few and far between.

* We now use Git 2.10.2 internally, which has brought with it numerous
  cleanups and a gradual shift away from 20 byte uchar arrays and toward the
  newer "object_id" structure.

== Downloading ==

* https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.xz sha256:
0889af29be15fc981481caa09579f982b9740fe9fd2860ab87dff286f4635890

* For verification git tag v1.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-

iQIzBAEBCAAdFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlg1HTsACgkQSfxwEqXe
A65/eA//Y0b2rVaPvwFuUbf3QEI2lm9yxgf5P2yzHGrbaHxeUjpzU57rpw39Xg6w
6SGwiu6ulSinVbz4deUUhvIfW8O9HoSGGnzLokePNosmIDyFreiHZUkp0looFspU
n22jLdcMgTt2ZsV0U6sReCD4fsrprs3pwlGQVUapshDP5laLo9xPiWNREMF7fJzi
BxFzsCO2jVM9L19tNVXkfJzSo+h/RqUD8lXh2HY0t8vCp44+23Mipx/rLgveWA8l
gpT0P5kcyFbD6j1WVZOUDaQG5BEGoPpZlCc8XaAdv574dznSfkTV2iO3JvqVtJn6
pJr1PXZVPsYY9n0NKmPPmj/Nv42ZhrfRnvfXpMPHRFyM890rHy7fksi2MhYo8hkK
ztKbcRx8zdI9mpcrZP3+ECgWY0AmgywWdeGYq5/3uBpPLhqXKCGNqh0+sraDC+/H
zk07Epl3cOsHXCphqJu9XSBNkr8XHSpZi/ifpK6aVtoz7GVK9+qnmH9lWUAvuzsq
w7sSj5R+onLsrn3X8RDkyp/rnIA9Duf+MpvHS6xqeYInjvBB4bwdhVfN4Ns+cYjf
6/u4r0+mlDyLn24gXzELUNW3wy4R7QgWcw5ZX0ItGKooOlRkYOmgrMyeeBNwaMs+
0BIA91TAsWpNIWUs0Dyhj/BnoEO5vf8iO+nE2CFpOAuats+Pj00=
=Dmc4
-END PGP SIGNATURE-
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Tag new release

[Jason A. Donenfeld]

Thanks for the reminder. In progress now.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.10.2

[Jason A. Donenfeld]

Looks good. Queue it up!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: RFC: don't cache objects larger than X

[Jason A. Donenfeld]

I think there actually might be a trick using rlimit to implement this
type of streaming size check...
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 2/3] shared: remove unused function strrpart()

[Jason A. Donenfeld]

LGTM.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-log: fix data corruption

[Jason A. Donenfeld]

So what's the verdict here? Do we have a double free or not?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: RFC: don't cache objects larger than X

[Jason A. Donenfeld]

I face this same problem, in fact. Unless somebody beats me to it, I'd
be interested in giving this a stab.

One issue is that cache entries are currently "streamed" into the
cache files, as they're produced. It's not trivially possible to know
how big it's going to be beforehand. This means that the best we could
do would be to just immediately unlink it after creation and printing.
Would this be acceptable?

Regards,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/3] ui-repolist: fix memory leak

[Jason A. Donenfeld]

Nice find, thanks. Queue 'er up.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 3/3] shared: remove unused function strlpart()

[Jason A. Donenfeld]

Also looks good.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-log: fix data corruption

[Jason A. Donenfeld]

Does this ever get freed, though?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-repolist: fix memory leak

[Jason A. Donenfeld]

Looks good to me.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.10.1

[Jason A. Donenfeld]

Thanks! Queue it up.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 02/10] ui-blob: replace 'unsigned char sha1[20]' with 'struct object_id oid'

[Jason A. Donenfeld]

On Tue, Oct 4, 2016 at 9:51 AM, Christian Hesse  wrote:
> +   hashcpy(walk_tree_ctx->matched_oid.hash, sha1);
> +   if (sha1_object_info(oid.hash, ) != OBJ_COMMIT)
> +   type = sha1_object_info(oid.hash, );
> +   type = sha1_object_info(oid.hash, );
> +   buf = read_sha1_file(oid.hash, , );
> +   type = sha1_object_info(oid.hash, );
> +   buf = read_sha1_file(oid.hash, , );

Presumably upstream git doesn't have an oid family of functions for these yet?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCHv2 0/2] Collapsible Section Support

[Jason A. Donenfeld]

Also, to clarify --

The patch for cgit for this should probably be just adding
id="section_name" to the various divs. Then users' stylesheets and js
files can contain the necessary logic for which to hide and when to
hide it. That is, unless you can think of some really slick way to
roll this out to everybody that isn't too invasive. But I'm leaning
toward the, "possible via section name IDs" approach.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCHv2 0/2] Collapsible Section Support

[Jason A. Donenfeld]

On Mon, Oct 3, 2016 at 5:44 PM, Andy Doan  wrote:
> I'll work up a dynamic version this today and throw it on another Linaro
> mirror so you can compare the differences.

Great! The unicode characters ▶, ▸, ▼, and ▾ might come in handy,
depending on how you implement it.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: css: highlight even table rows

[Jason A. Donenfeld]

Honestly I thought it was really ugly at first. But then I tried it
out on git.zx2c4.com and forgot about it, and now after looking at it
for a bunch of months, I don't mind it. So apparently you and
kernel.org both like this. So maybe I should merge it.

Does anybody have any objections due to aesthetic reasons?
The latest has been deployed again to git.zx2c4.com .
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] cgit: ignore SIGPIPE

[Jason A. Donenfeld]

Hey John,

I see the utility of this with something like a highlight filter gone
bad. But is it safe to do this in the context of an authentication
filter? What's the failure behavior like once this patch is applied?

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCHv2 0/2] Collapsible Section Support

[Jason A. Donenfeld]

Hey Andy,

One issue with this is -- isn't this the sort of thing that would be
better taken care of with css3 or css+javascript? That is to say you
list the children of some elements as being display:none until they're
clicked, and then upon click you make it visible? This seems like it'd
be a bit slicker of an interface too. Would this be an acceptable
interface?

Regards,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PULL] Various patches from the list

[Jason A. Donenfeld]

Hey John,

I merged all of this except the last two commits, which I'd like to
discuss a bit more. Those live in jk/collapsible-sections. I'll chime
in on the other thread about that.

Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Simplify http_parse_querystring()

[Jason A. Donenfeld]

This looks sane to me. It results in more allocations, but I think
that's a moot point compared to the nice code simplifications and
deduplication.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: trac integration

[Jason A. Donenfeld]

Hi Ferry,

I suppose this would be something for the contrib/ section. I wouldn't
be all together opposed to filling this directory with lots of
different integrations for various project management applications,
web servers, and so forth, but one pitfall I've seen numerous times in
my projects and others is that these go stale and get abandoned fairly
quickly, but nobody realizes because it's alongside the active
project. On the other hand, when it's in a separate repo, it's easier
to see how active it is and what the status is. So, I see both the
advantages of it and disadvantages to integrating it into the cgit
repository.

If we do wind up keeping it in its own repository and not integrating
it into cgit's, of course I'd be happy to host this on git.zx2c4.com
alongside cgit, and give you ownership over the repo.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Development Flow Improvements

[Jason A. Donenfeld]

Hey folks,

I wanted to update you on a conversation a few of us have been having
off-list. In order to hasten the speed of development, we're making
some changes to the way things are done.

All submitted patch series will now live in feature branches. Each
feature branch will be owned by either me (jd), John (jk), Christian
(ch), Ferry (fh), Lukas (lf), or Lars (lh), and will be titled
something like "jk/add-links-to-header". After enough review, and the
feature is ready to land, it will be put into the owner's "for-jason"
branch -- such as "ch/for-jason". Then, when I'm ready, I'll review
and sweep up all the various */for-jason branches (including my own!)
into master, and sometime after that cut a release.

This should pick up the pace a little bit, because it enables any of
us to more easily review a patch series and get it ready for final
inclusion. So, if you submit a patch series, and you get a reply from
me, John, Christian, Ferry, Lukas, or Lars, saying something like,
"I'll review this," it means it should shortly after wind up in a
feature branch on .

I think this will work out well. Looking forward to finally see some
patches land.

Regards,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v5 1/1] ui-shared: allow to split the repository link

[Jason A. Donenfeld]

It looks mostly good to me. I'll get this in the next release.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] RFC: git: update to v2.10.0-rc0

[Jason A. Donenfeld]

On Aug 15, 2016 12:02 PM, "Juuso Lapinlampi"  wrote:
>
> Please keep the latest Git submodule at a stable version, e.g. 2.9.3 for
> master branch. I'm okay with this change being in a pu branch, to be
> merged to next and eventually master later. (Ignoring the fact that cgit
> doesn't have those branches, currently.)
>
> Note that I'm not a maintainer of cgit.

I am! Worry not: this is just to examine the general shape of the changes
required. I'll probably cut a new cgit release around the time of the git
release, so it's nice to start discussing the changes early, hence this RFC.

Back from holidays late tonight, and merges will resume.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 13/16] Add documentation for repo.namespace

[Jason A. Donenfeld]

On Sat, Jul 16, 2016 at 12:59 AM, Richard Maw  wrote:
> Signed-off-by: Richard Maw 
> ---
>  cgitrc.5.txt | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/cgitrc.5.txt b/cgitrc.5.txt
> index 9fcf445..6116d1b 100644
> --- a/cgitrc.5.txt
> +++ b/cgitrc.5.txt
> @@ -570,6 +570,10 @@ repo.max-stats::
>  repo.name::
> The value to show as repository name. Default value: .
>
> +repo.namespace::
> +   Set the git namespace, so that fetching and cloning only provide refs
> +under refs/namespaces. Default value: none.

Mixed tabs and spaces it appears.

This does more than just fetching and cloning, right? It's supposed to
affect the whole displayed view of cgit?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 12/16] Display notes from namespace

[Jason A. Donenfeld]

On Sat, Jul 16, 2016 at 12:59 AM, Richard Maw  wrote:
> +   if (ref_exists(namespaced_note_ref.buf)) {
> +   if (has_glob_specials(namespaced_note_ref.buf)) {
> +   for (const char *c = namespaced_note_ref.buf; 
> *c; c++) {
> +   if (is_glob_special(*c))
> +   
> strbuf_addchars(_escaped, '\\', 1);
> +   strbuf_addchars(_escaped, *c, 1);

Could you explain why this is necessary? Why are the extra refs globs
exactly? Does git core have a convenience function for this?

> +   }
> +   string_list_append(_notes_refs, 
> glob_escaped.buf);
> +   } else {
> +   string_list_append(_notes_refs, 
> namespaced_note_ref.buf);
> +   }

else
single-statement;


> +   }
> +
> +   init_display_notes();
> +   string_list_clear(_notes_refs, 1);
> +   strbuf_release(_escaped);
> +   strbuf_release(_note_ref);
> +   } else {
> +   init_display_notes(NULL);
> +   }

else
init_display_notes(NULL);
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 11/16] Add namespace support to dumb-clone

[Jason A. Donenfeld]

On Sat, Jul 16, 2016 at 12:59 AM, Richard Maw  wrote:
> +   unsigned char unused[20];
> +   char *namespaced_head = NULL;
> +   const char *ref;
> +   namespaced_head = mkpathdup("%sHEAD", get_git_namespace());
> +   /* NOTE: RESOLVE_REF_NO_RECURSE is required to prevent it 
> resolving HEAD
> +  into a ref outside of the namespace. */
> +   ref = resolve_ref_unsafe(namespaced_head, 
> RESOLVE_REF_NO_RECURSE, unused, NULL);

This funny business is duplicated from a previous patch.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 07/16] Guess the default branch based on current namespace

[Jason A. Donenfeld]

On Sat, Jul 16, 2016 at 12:59 AM, Richard Maw  wrote:
> -
> -   ref = resolve_ref_unsafe("HEAD", 0, sha1, NULL);
> -   if (!ref || !starts_with(ref, "refs/heads/"))
> +   char *namespaced_head = NULL;
> +
> +   if (get_git_namespace())
> +   namespaced_head = mkpathdup("%sHEAD", get_git_namespace());
> +   /* NOTE: RESOLVE_REF_NO_RECURSE is required to prevent it resolving 
> HEAD
> +  into a ref outside of the namespace. */
> +   ref = resolve_ref_unsafe(namespaced_head ?: "HEAD", 
> RESOLVE_REF_NO_RECURSE, sha1, NULL);

Except now, for the non-namespaced case, we don't recurse on symbolic
entries, which might not be desirable.

Rather than this, would it be possible to make the underlying upstream
function namespace aware? By the environment variable perhaps?

> +   free(namespaced_head);
> +   if (!ref || !starts_with(strip_namespace(ref), "refs/heads/"))
> return "master";
> -   return xstrdup(ref + 11);
> +   return xstrdup(strip_namespace(ref) + 11);
>  }
>  /* The caller must free filename and ref after calling this. */
>  static inline void parse_readme(const char *readme, char **filename, char 
> **ref, struct cgit_repo *repo)
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 06/16] Look up refs in namespace with cgit_get_sha1

[Jason A. Donenfeld]

On Sat, Jul 16, 2016 at 12:59 AM, Richard Maw  wrote:
> +static int namespaced_dwim_ref_get_sha1(const char *name, unsigned char 
> *sha1)
> +{
> +   /* The standard git name disambiguation order is:
> +$name
> +refs/$name
> +refs/tags/$name
> +refs/heads/$name
> +refs/remotes/$name (not sure why)
> +refs/remotes/$name/HEAD
> +  we don't care about remotes, so we can skip those,
> +  and we can't specify a prefix for dwm_ref,
> +  so we have to do this ourselves */
> +   static const char *namespaced_ref_patterns[] = {
> +   "%s%s",
> +   "%srefs/%s",
> +   "%srefs/tags/%s",
> +   "%srefs/heads/%s",
> +   NULL,
> +   };
> +   const char **p;
> +
> +   for (p = namespaced_ref_patterns; *p; p++) {
> +   char *fullref = NULL;
> +   const char *r;
> +   fullref = mkpathdup(*p, get_git_namespace(), name);
> +   r = resolve_ref_unsafe(fullref, RESOLVE_REF_READING, sha1, 
> NULL);
> +   free(fullref);
> +   if (r)
> +   return 0;
> +   }
> +   return 1;
> +}
> +
>  int cgit_get_sha1(const char *name, unsigned char *sha1)
>  {
> -   return get_sha1(name, sha1);
> +   if (ctx.repo->namespace) {
> +   /* If we have a namespace, we can get either a sha1,
> +  or a possibly abbreviated ref.
> +  Advanced ref forms are not supported at this time
> +  as this would require reimplementing all of ref parsing.
> +  If get_sha1_with_context grows support for a namespaced 
> flag
> +  then this code may go away. */
> +   if (get_sha1_hex(name, sha1) == 0)
> +   return 0;
> +   return namespaced_dwim_ref_get_sha1(name, sha1);

Ugh. This manual ref lookup is really ugly and unfortunate. I don't
like having to duplicate the code like this. What would you think of
adding the flag to upstream, so that the functions are namespace
aware, and then this becomes unnecessary?



> +   } else {
> +   return get_sha1(name, sha1);
> +   }


Get rid of the else clause, and just put "return get_sha1(name,
sha1);" unintended as the last line of the function.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 00/16] [V2] Add namespace support to cgit

[Jason A. Donenfeld]

Thanks for the reminder! I'll take a look tomorrow morning.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 03/17] Add a wrapper for get_sha1 called cgit_get_sha1

[Jason A. Donenfeld]

On Tue, Jul 12, 2016 at 11:16 AM, Richard <richard@gmail.com> wrote:
> On 12 July 2016 at 00:12, Jason A. Donenfeld <ja...@zx2c4.com> wrote:
>> Sorry for the churn here, but this doesn't apply, due to Lukas' recent
>> patch. Could you respin this?
>
> Sure thing, I should hopefully have this done late wednesday evening.
>
>> By the way, feel free to alternatively submit this series with
>> git-request-pull if you've got it in a repo somewhere.
>
> That's a new one to me. I like patches on a mailing list for feedback,
> but applying by e-mail is a faff, so sticking the output of
> git-request-pull in the cover letter might be the best of both worlds
> for me.
>
> If you'd prefer just the request-pull text I can do that.

It's however you wish. Both forms work well for me.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 03/17] Add a wrapper for get_sha1 called cgit_get_sha1

[Jason A. Donenfeld]

Sorry for the churn here, but this doesn't apply, due to Lukas' recent
patch. Could you respin this?

By the way, feel free to alternatively submit this series with
git-request-pull if you've got it in a repo somewhere.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.9.1

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] css: highlight even table rows

[Jason A. Donenfeld]

This seems not to work as well on the log:
https://git.zx2c4.com/cgit/log/
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v2] Link with -ldl on GNU/kFreeBSD

[Jason A. Donenfeld]

Seems like a more sensible approach. I'll merge this and see if
anybody complains.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Fix spelling in man page

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Avoid ambiguities when prettifying snapshot names

[Jason A. Donenfeld]

Hey Lukas,

I appreciate that this unifies the 'v' detection code as well. I also
like the "(a==0 + b==0 + c==0) == 1" trick. I'll merge this, and base
the fixes for tags with / in them on this commit.

Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 2/2] css: consistent use of empty lines

[Jason A. Donenfeld]

I merged this series, but applied John's suggestion of not doing the
extra trailing line.

Thanks Christian.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: contrib examples

[Jason A. Donenfeld]

UGH. Wrong list.

Sorry guys.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

contrib examples

[Jason A. Donenfeld]

Hi guys,

I've started compiling various example scripts of `wg(8)` usage in
contrib/examples [1]. The ncat-client-server [2] one is the insecure
script folks are currently using for testing their install with demo
dot wireguard dot io. The systemd one [3] is the hairy
wgserver.service test unit file. And now I've just added one for
synergy over wireguard [4], the keyboard/mouse sharing utility that's
too scary of a project not to isolate to a wireguard tunnel.

If anyone else comes up with various examples and easy use cases, I'd
be happy to add a script or twenty to contrib/examples. Each of the
current scripts has a descriptive README.

Jason

[1] https://git.zx2c4.com/WireGuard/tree/contrib/examples
[2] https://git.zx2c4.com/WireGuard/tree/contrib/examples/ncat-client-server
[3] https://git.zx2c4.com/WireGuard/tree/contrib/examples/systemd
[4] https://git.zx2c4.com/WireGuard/tree/contrib/examples/synergy
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 00/17] Add support for namespaced repositories

[Jason A. Donenfeld]

Hi Richard,

This looks like really cool work. I'll review it this week and get
back to you. Thanks for submitting.

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-log: color line changes

[Jason A. Donenfeld]

Hey Christian,

This is very pretty. I'll test drive it for a few days, but I like it
overall.

[image: Inline image 1]

Thanks for the patch!

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] Link with -ldl on GNU/kFreeBSD

[Jason A. Donenfeld]

Hey Peter,

I wonder if a better way would be match the particular libc out of
uname -o. In this case, GNU libc needs -ldl. Do other libcs also need
libdl? Seems like this might be slightly cleaner.

Any opinions on this list?

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: RFC: Hide/show inactive repos in index

[Jason A. Donenfeld]

I'll try to hook this up to the lua scripting.

On holiday now in Japan, but I'll write more later when back at a real PC.
On Jun 3, 2016 10:46 PM, "Konstantin Ryabitsev"  wrote:

> Hi, all:
>
> It would be handy to have a way to hide inactive repositories from the
> main index -- say, the ones that haven't seen any activity in a few
> years.
>
> One solution is not to put older repositories into the projects.list,
> but that would make them completely unfindable unless someone knows the
> full path.
>
> Another solution is to rig up some kind of jquery magic that would hide
> the rows containing , but that sounds really hurky and would be fragile.
>
> Maybe have a way to give a row a class "inactive" from a setting in the
> repo's git config (or from a repo.foo cgitrc setting), and have a button
> to "show/hide inactive projects" on the index page?
>
> Thoughts?
>
> Best,
> --
> Konstantin Ryabitsev
> Linux Foundation Collab Projects
> Montréal, Québec
>
> ___
> CGit mailing list
> CGit@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit
>
>
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.7.4

[Jason A. Donenfeld]

Does that vuln apply to our usage of libgit?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.8.3

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/5] ui-shared: HTML-ize DOCTYPE and

[Jason A. Donenfeld]

This is live on git.zx2c4.com . So far it looks good to me.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-shared: Use CRLF in HTTP headers as per RFC 7230

[Jason A. Donenfeld]

On Wed, May 11, 2016 at 7:48 PM, Juuso Lapinlampi  wrote:
> CRLF is explicitly defined as the line break in the HTTP protocol
> specifications: RFC 2616 (obsolete) and RFC 7230.

But this is CGI, not HTTP.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 5/5] ui-shared: Remove a name attribute with an empty value

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 4/5] ui: Fix bad value for attribute action on form elements

[Jason A. Donenfeld]

Could we instead just remove action? Does this work both in the case
of path/to/page and path/to/page/ ? Or in the former will this wind up
requesting path/to/.?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/5] ui-shared: HTML-ize DOCTYPE and

[Jason A. Donenfeld]

On Wed, May 11, 2016 at 8:56 PM, John Keeping  wrote:
> This seems like a reasonable aim, but don't we need to actually *be*
> HTML(5?) as well in order to do this?  Currently we close  and
>  tags even though HTML is explicit that this shouldn't be done.

No, in HTML5 you can do it if you want but you don't have to.
http://blog.teamtreehouse.com/to-close-or-not-to-close-tags-in-html5
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/5] ui-shared: HTML-ize DOCTYPE and

[Jason A. Donenfeld]

On Wed, May 11, 2016 at 8:04 PM, Juuso Lapinlampi  wrote:
>
>  static const char cgit_doctype[] =
> -" -"  \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;>\n";
> +""\n";

Not syntactically valid C either. Test your commits before you submit.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-shared: Simplify cgit_print_error_page() logic

[Jason A. Donenfeld]

On Wed, May 11, 2016 at 7:50 PM, Juuso Lapinlampi  wrote:
> -   cgit_print_docstart();
> -   cgit_print_pageheader();
> +   cgit_print_layout_start()
> va_start(ap, fmt);

You forgot a semicolon. Please test your commits before you submit.
Otherwise you waste everyone's time.

Fixed it up myself.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 2/5] Revert "ui-summary: add "rel='vcs-git'" to clone URL links"

[Jason A. Donenfeld]

Hi Paul,

We added vcs-git per your request [1]. Now there's talk of removing it.

Could you give full justification for its existence? How is it useful?
What uses it?

Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/5] ui-shared: HTML-ize DOCTYPE and

[Jason A. Donenfeld]

Merged!

It's time we grow up.

If this causes rendering errors due to compatibility modes the prior
XHTML header was triggering, we can fix those up in subsequent
commits.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] ui-shared: Simplify cgit_print_error_page() logic

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v4] ui-shared: allow to split the repository link

[Jason A. Donenfeld]

Can you rename this from "summary-enable-split-repo-link" to
"split-summary-repo-link"?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.8.2

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 2/2] ui-log: Simplify decoration code

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-log: Do not always emit decoration span

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH v2 1/1] scan-tree: handle error in git_config_from_file()

[Jason A. Donenfeld]

Are repos without .git/config necessarily invalid?

zx2c4@thinkpad ~ $ mkdir abcd
zx2c4@thinkpad ~ $ cd abcd
zx2c4@thinkpad ~/abcd $ git init
Initialized empty Git repository in /home/zx2c4/abcd/.git/
zx2c4@thinkpad ~/abcd $ touch file
zx2c4@thinkpad ~/abcd $ git add file
zx2c4@thinkpad ~/abcd $ git commit -m first
[master (root-commit) 55749f6] first
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file
zx2c4@thinkpad ~/abcd $ rm .git/config
zx2c4@thinkpad ~/abcd $ git status
On branch master
nothing to commit, working directory clean
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] scan-tree: handle error in git_config_from_file()

[Jason A. Donenfeld]

Are repos without .git/config necessarily invalid?

zx2c4@thinkpad ~ $ mkdir abcd
zx2c4@thinkpad ~ $ cd abcd
zx2c4@thinkpad ~/abcd $ git init
Initialized empty Git repository in /home/zx2c4/abcd/.git/
zx2c4@thinkpad ~/abcd $ touch file
zx2c4@thinkpad ~/abcd $ git add file
zx2c4@thinkpad ~/abcd $ git commit -m first
[master (root-commit) 55749f6] first
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file
zx2c4@thinkpad ~/abcd $ rm .git/config
zx2c4@thinkpad ~/abcd $ git status
On branch master
nothing to commit, working directory clean
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: premature exits bork cache

[Jason A. Donenfeld]

Ahh, good point.

There are a couple more calls to exit that I'm investigating. This is
certainly not the nicest way to handle things...
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

Welp, in the last 2 days:

krantz log # grep git-daemon messages | grep 'Connection from' | wc -l
3079

So, I guess git:// will be sticking around, alas.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

premature exits bork cache

[Jason A. Donenfeld]

Hi guys,

When caching is turned on, if we exit(0) early from a cmd, the cache
won't be properly finalized (or even sent), and we get a server error
because of blank output. I just fixed this bug with redirect:

https://git.zx2c4.com/cgit/commit/?id=e9cbdf64632fbe64d6b0c4974ac947ef954938e7

This is fine, because it's called only from 1 function (three times),
and that function then returns, so execution doesn't continue after
the redirect. It simply gives control back to the caching layer that
does things properly now.

But I noticed we have this issue with HTTP HEAD method:

https://git.zx2c4.com/cgit/tree/ui-shared.c#n695

Here we're calling exit(0). The motivation, I imagine, was that we
want to retain the same handlers, but just return the headers for the
HEAD method. Unfortunately, this borks the cache layer for the same
reasons as described above. I'm not yet sure the cleanest way to fix
this. Suggestions?

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

cgit builds with link time optimization

[Jason A. Donenfeld]

For the ricers out there, this might be desirable:

https://git.zx2c4.com/cgit/tree/cgit.conf?h=jd/zx2c4-deployment
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: cgit: [PATCH] timegm() compat for non-Linux and non-BSD

[Jason A. Donenfeld]

Thanks for posting that thread. I'd forgotten about that. I think my
views there are still solid:

We either use the hack from the manpage (which is what Brad's patch
does), or, so that we don't have to make compatibility infrastructure,
we simply work around this function so that we don't need it. Seeing
as it's only used in one place, I dont think this will be a problem.
I'll gladly accept a patch that fixes that.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: why no process info when cloning

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 10:45 AM, John Keeping  wrote:
> It's because CGit only supports the dumb HTTP protocol whereas GitHub
> supports the smart protocol.  git-http-backend(1) describes how to set
> up a webserver for to support the smart protocol.
>
> [aside: given the inefficiency of the dumb HTTP protocol I wonder if we
> should mark this features as deprecated in the CGit documentation, or at
> least add a WARNING to it.]

Rather than marking this as depreciated - this very useful feature of
cgit - since we share source with git, wouldn't it be possible to
integrate the smart protocol?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit