From actionmystique at gmail.com  Mon Dec 12 14:02:36 2022
From: actionmystique at gmail.com (jean-christophe manciot)
Date: Mon, 12 Dec 2022 15:02:36 +0100
Subject: git 2.38.2
Message-ID: <CAKcFC3ZRzvbLsJdAhiYwWwTqN4uHtpNx84=zNN03GnVomcrXGg@mail.gmail.com>

Isn't there a need for a cgit patch for the new git 2.38.2 release?
Thanks,
-- 
Jean-Christophe

From list at eworm.de  Mon Dec 12 15:25:25 2022
From: list at eworm.de (Christian Hesse)
Date: Mon, 12 Dec 2022 16:25:25 +0100
Subject: [PATCH 1/1] git: update to v2.39.0
Message-ID: <20221212152525.99695-1-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Update to git version v2.39.0, no additional changes required.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 Makefile | 2 +-
 git      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index b9bdaf8..cd7639c 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,7 @@ htmldir = $(docdir)
 pdfdir = $(docdir)
 mandir = $(prefix)/share/man
 SHA1_HEADER = <openssl/sha.h>
-GIT_VER = 2.38.2
+GIT_VER = 2.39.0
 GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.xz
 INSTALL = install
 COPYTREE = cp -r
diff --git a/git b/git
index 8706a59..c48035d 160000
--- a/git
+++ b/git
@@ -1 +1 @@
-Subproject commit 8706a59933d09354c5e3eb09a543453655a97183
+Subproject commit c48035d29b4e524aed3a32f0403676f0d9128863
-- 
2.38.2


From list at eworm.de  Fri Dec 16 17:50:26 2022
From: list at eworm.de (Christian Hesse)
Date: Fri, 16 Dec 2022 18:50:26 +0100
Subject: [PATCH 1/1] ui-log: show ellipsis if detailed commit message is
 available
Message-ID: <20221216175026.125944-1-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

The existence of a detailed commit message may be of interst even
if only the subject is shown by default.
---
 cgit.css | 8 ++++++++
 ui-log.c | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/cgit.css b/cgit.css
index dfa144d..97fd9c8 100644
--- a/cgit.css
+++ b/cgit.css
@@ -669,6 +669,14 @@ div#cgit div.footer a:hover {
 	text-decoration: underline;
 }
 
+div#cgit span.msg-avail {
+	color: #000;
+	margin: 0px 0.5em;
+	padding: 0px 0.25em;
+	background-color: #f0f0f0;
+	border: solid 1px #777777;
+}
+
 div#cgit a.branch-deco {
 	color: #000;
 	margin: 0px 0.5em;
diff --git a/ui-log.c b/ui-log.c
index 565929f..26701fb 100644
--- a/ui-log.c
+++ b/ui-log.c
@@ -240,6 +240,8 @@ static void print_commit(struct commit *commit, struct rev_info *revs)
 	}
 	cgit_commit_link(info->subject, NULL, NULL, ctx.qry.head,
 			 oid_to_hex(&commit->object.oid), ctx.qry.vpath);
+	if (!ctx.qry.showmsg && strlen(info->msg) > 0)
+		html("<span class='msg-avail'>...</span>");
 	show_commit_decorations(commit);
 	html("</td><td>");
 	cgit_open_filter(ctx.repo->email_filter, info->author_email, "log");
-- 
2.39.0


From leah at vuxu.org  Sun Dec 18 18:38:56 2022
From: leah at vuxu.org (Leah Neukirchen)
Date: Sun, 18 Dec 2022 19:38:56 +0100
Subject: cache: sendfile(2) usage results in short writes to pipes
Message-ID: <87v8m8pnen.fsf@vuxu.org>

Hi,

in cache.c:print_slot, sendfile is called only once, but not checked
for short writes.  These happen for example when serving cgit via
fcgiwrap, which uses a pipe, so the write only writes 65k:

[pid 31211] openat(AT_FDCWD, "/var/cache/cgit/b9200000", O_RDONLY) = 4
[pid 31211] fstat(4, {st_mode=S_IFREG|0600, st_size=19824215, ...}) = 0
[pid 31211] read(4, "mirror/glibc/snapshot/glibc-3aae"..., 4096) = 4096
[pid 31211] sendfile(1, 4, [77] => [65536], 19824138) = 65459
[pid 31211] close(4 <unfinished ...>

This results in truncated cache responses, and therefore broken
downloads from snapshots (larger than 65k).

I assume this is also the cause for the bug reported in
<0ef89b1e-6543-e726-2cf0-b68e7167fabe at odo.lv>, I added the author to Cc:.

I recommend running sendfile in a loop until the whole file is sent.
I also recommend detecting sendfile errors and falling back to the
default read/write implementation, as there are some Linux filesystems
where sendfile fails permanently.

Disabling HAVE_LINUX_SENDFILE on build serves as a workaround.

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From Jason at zx2c4.com  Mon Dec 19 14:28:12 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 19 Dec 2022 15:28:12 +0100
Subject: [PATCH] ui-commit: use Git raw note format
In-Reply-To: <87sgdp90gm.fsf@alyssa.is>
References: <20190526165701.28904-1-aklhfex@gmail.com>
 <87sgdp90gm.fsf@alyssa.is>
Message-ID: <CAHmME9pWUKU7gmAw6j=3jb-sY6+Dz5GSjStkJt96=8ZYAMvmEQ@mail.gmail.com>

Wondering what the purpose of this is? Why would you prefer this
format over the other one?

From Jason at zx2c4.com  Mon Dec 19 14:31:59 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 19 Dec 2022 15:31:59 +0100
Subject: [PATCH] ui-repolist,
 ui-shared: remove redundant title on repo anchors
In-Reply-To: <20190315201705.32714-1-aklhfex@gmail.com>
References: <20190315201705.32714-1-aklhfex@gmail.com>
Message-ID: <CAHmME9qALk8hZLhuyp=S7VqMZvxux0eR4+Zh795wCAwqdPuD3A@mail.gmail.com>

Applied, thanks.

Jason

From hi at alyssa.is  Mon Dec 19 14:35:32 2022
From: hi at alyssa.is (Alyssa Ross)
Date: Mon, 19 Dec 2022 14:35:32 +0000
Subject: [PATCH] ui-commit: use Git raw note format
In-Reply-To: <CAHmME9pWUKU7gmAw6j=3jb-sY6+Dz5GSjStkJt96=8ZYAMvmEQ@mail.gmail.com>
References: <20190526165701.28904-1-aklhfex@gmail.com>
 <87sgdp90gm.fsf@alyssa.is>
 <CAHmME9pWUKU7gmAw6j=3jb-sY6+Dz5GSjStkJt96=8ZYAMvmEQ@mail.gmail.com>
Message-ID: <20221219143532.uig3efsubbq4646b@x220>

On Mon, Dec 19, 2022 at 03:28:12PM +0100, Jason A. Donenfeld wrote:
> Wondering what the purpose of this is? Why would you prefer this
> format over the other one?

The current format says "Notes" twice in a row, as exemplified in the
patch description.  It's redundant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20221219/ac0d88ad/attachment.sig>

From Jason at zx2c4.com  Mon Dec 19 15:17:16 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 19 Dec 2022 16:17:16 +0100
Subject: cache: sendfile(2) usage results in short writes to pipes
In-Reply-To: <87v8m8pnen.fsf@vuxu.org>
References: <87v8m8pnen.fsf@vuxu.org>
Message-ID: <CAHmME9r_FcyT4KqZj9wuD9fSFGB4-1AQL7=4+pg=HVAeAec5_g@mail.gmail.com>

Fixed in the master branch now.

From valdis.vitolins at odo.lv  Thu Dec 22 08:58:00 2022
From: valdis.vitolins at odo.lv (=?UTF-8?B?VmFsZGlzIFbEq3RvbGnFhsWh?=)
Date: Thu, 22 Dec 2022 10:58:00 +0200
Subject: cache: sendfile(2) usage results in short writes to pipes
In-Reply-To: <87wn6opniu.fsf@vuxu.org>
References: <87wn6opniu.fsf@vuxu.org>
Message-ID: <8839a585-09fd-f672-871c-5fe58e98f82c@odo.lv>

Hi, Leah!

Do I understand you correctly that, when compiling and deploying cgit
according to https://git.zx2c4.com/cgit/tree/README

before compilation I should add in Makefile:
HAVE_LINUX_SENDFILE = 1

Thanks!
Valdis

> Hi,
> 
> in cache.c:print_slot, sendfile is called only once, but not checked
> for short writes.  These happen for example when serving cgit via
> fcgiwrap, which uses a pipe, so the write only writes 65k:
> 
> [pid 31211] openat(AT_FDCWD, "/var/cache/cgit/b9200000", O_RDONLY) = 4
> [pid 31211] fstat(4, {st_mode=S_IFREG|0600, st_size=19824215, ...}) = 0
> [pid 31211] read(4, "mirror/glibc/snapshot/glibc-3aae"..., 4096) = 4096
> [pid 31211] sendfile(1, 4, [77] => [65536], 19824138) = 65459
> [pid 31211] close(4 <unfinished ...>
> 
> This results in truncated cache responses, and therefore broken
> downloads from snapshots (larger than 65k).
> 
> I assume this is also the cause for the bug reported in
> <0ef89b1e-6543-e726-2cf0-b68e7167fabe at odo.lv>, I added the author to Cc:.
> 
> I recommend running sendfile in a loop until the whole file is sent.
> I also recommend detecting sendfile errors and falling back to the
> default read/write implementation, as there are some Linux filesystems
> where sendfile fails permanently.
> 
> Disabling HAVE_LINUX_SENDFILE on build serves as a workaround.
> 
> cu,