cgit/ui-patch.c, branch v1.2

cache: flush stdio before restoring FDs

2017-10-03T18:19:34Z

As described in commit 2efb59e (ui-patch: Flush stdout after outputting data, 2014-06-11), we need to ensure that stdout is flushed before restoring the file descriptor when writing to the cache. It turns out that it's not just ui-patch that is affected by this but also raw diff which writes to stdout internally. Let's avoid risking more places doing this by ensuring that stdout is flushed after writing in fill_slot(). Signed-off-by: John Keeping

git: update to v2.14

2017-08-10T13:58:24Z

Numerous changes were made to git functions to use an object_id structure rather than sending sha1 hashes as raw unsigned character arrays. The functions that affect cgit are: parse_object, lookup_commit_reference, lookup_tag, lookup_tree, parse_tree_indirect, diff_root_tree_sha1, diff_tree_sha1, and format_display_notes. Commit b2141fc (config: don't include config.h by default) made it necessary to that config.h be explicitly included when needed. Commit 07a3d41 (grep: remove regflags from the public grep_opt API) removed one way of specifying the ignore-case grep option. Signed-off-by: Jeff Smith

ui-patch: fix crash when using path limit

2017-01-23T17:36:04Z

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

patch: reapply path limit

2016-10-12T11:28:15Z

This was originally applied added in commit eac1b67 (ui-patch: Apply path limit to generated patch, 2010-06-10) but the ability to limit patches to particular paths was lost in commit 455b598 (ui-patch.c: Use log_tree_commit() to generate diffs, 2013-08-20). The new output is slightly different from the original because Git's diff infrastructure doesn't give us a way to insert an annotation immediately after the "---" separator, so the commit has moved below the diff stat. Signed-off-by: John Keeping

ui-patch: replace 'unsigned char sha1[20]' with 'struct object_id oid'

2016-10-04T07:47:18Z

Upstream git is replacing 'unsigned char sha1[20]' with 'struct object_id oid'. We have some code that can be changed independent from upstream. So here we go...

git: update to v2.7.0

2016-01-13T16:12:17Z

Update to git version v2.7.0. * Upstream commit ed1c9977cb1b63e4270ad8bdf967a2d02580aa08 (Remove get_object_hash.) changed API: Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: Christian Hesse

patch: use cgit_print_error_page() for HTTP status codes

2015-08-14T13:46:51Z

Signed-off-by: John Keeping

ui-patch: make sure to send http headers

2015-08-14T10:35:25Z

Requesting a text/plain patch with bad commit id made cgit send text without proper http headers. This results in "500 Internal Server Error" with "Premature end of script headers" in server logs. So print http headers before error message and return. Signed-off-by: Christian Hesse Reviewed-by: John Keeping

ui-patch: match git-format-patch(1) output

2014-12-28T13:44:44Z

Using (DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH) causes Git to emit a "---" line between the commit message and the body of the patch, which fixes a regression introduced in commit 455b598 (ui-patch.c: Use log_tree_commit() to generate diffs, 2013-08-20), prior to which we inserted the "---" line ourselves. DIFF_FORMAT_SUMMARY is added so that we match the output of git-format-patch(1) without the "-p" option. Signed-off-by: John Keeping

ui-patch: Flush stdout after outputting data

2014-06-28T13:59:15Z

It looks like cached patches are truncated to the nearest 1024-byte boundary in the patch body. E.g.: > mricon@nikko:[/tmp]$ wget -O no-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6e1b4fdad5157bb9e88777d525704aba24389bee" ... > 2014-06-11 15:34:51 (80.4 MB/s) - ‘no-cache’ saved [4767] Patch is complete, without truncation. Next hit, with cache in place: > mricon@nikko:[/tmp]$ wget -O yes-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6e1b4 > fdad5157bb9e88777d525704aba24389bee" ... > 2014-06-11 15:35:01 (17.0 MB/s) - ‘yes-cache’ saved [4096/4096] Length truncated to 4096. The cache on disk looks truncated as well, so the bug must me during the process of saving cache. The same is true for larger patches: > mricon@nikko:[/tmp]$ wget -O no-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2840c566e95599cd60c7143762ca8b49d9395050" ... > 2014-06-11 15:41:33 (1.07 MB/s) - ‘no-cache’ saved [979644] 979644 bytes with a cache-miss > mricon@nikko:[/tmp]$ wget -O yes-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2840c > 566e95599cd60c7143762ca8b49d9395050" ... > 2014-06-11 15:41:46 (1.05 MB/s) - ‘yes-cache’ saved [978944] 978944 (956KB exactly) with a cache-hit Since the "html" functions use raw write(2) to STDIO_FILENO, we don't notice problems with most pages, but raw patches write using printf(3). This is fine if we're outputting straight to stdout since the buffers are flushed on exit, but we close the cache output before this, so the cached output ends up being truncated. Make sure the buffers are flushed when we finish outputting a patch so that we avoid this. No other UIs use printf(3) so we do not need to worry about them. Actually, it's slightly more interesting than this... since we don't set GIT_FLUSH, Git decides whether or not it will flush stdout after writing each commit based on whether or not stdout points to a regular file (in maybe_flush_or_die()). Which means that when writing directly to the webserver, Git flushes stdout for us, but when we redirect stdout to the cache it points to a regular file so Git no longer flushes the output for us. The patch is still correct, but perhaps the full explanation is interesting! Reported-by: Konstantin Ryabitsev