Re: [PATCH] t5562: do not reuse output files

2018-11-27 Thread Max Kirillov
On Mon, Nov 26, 2018 at 11:06:40AM +0900, Junio C Hamano wrote: > I am offhand not sure what the right value of wait_after_clean for > this codepath be, though. 46df6906 ("execv_dashed_external: wait > for child on signal death", 2017-01-06) made this non-default but > turned it on for dashed

[PATCH] http-backend: enable cleaning up forked upload/receive-pack on exit

2018-11-24 Thread Max Kirillov
keep opened act.err, and sometimes write there errors after next test started using the file. Fix by enabling cleaning of the command at http-backed exit. Reported-by: Carlo Arenas Helped-by: Carlo Arenas Signed-off-by: Max Kirillov --- This seems to fix the issue at NetBSD. I verified

Re: [PATCH] t5562: do not reuse output files

2018-11-24 Thread Max Kirillov
On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote: > I do agree that forcing the parent to wait, like you described in > the comment, would be far more preferrable, It looks like it can be done as simple as: --- a/http-backend.c +++ b/http-backend.c @@ -486,6 +486,8 @@ static void

[PATCH v3] t5562: do not reuse output files

2018-11-24 Thread Max Kirillov
occasional failures of the test script. Avoid the issue by using separated output and error file for each test, apprending the test number to their name. Reported-by: Carlo Arenas Helped-by: Carlo Arenas Helped-by: Junio C Hamano Signed-off-by: Max Kirillov --- Use another output and error files

Re: [PATCH] t5562: do not reuse output files

2018-11-23 Thread Max Kirillov
On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > a better workaround might be to write into unique output filenames > (act1.out, act2.out, etc.); that way, you do not have to worry about > the output file for the next request getting clobbered by a stale

[PATCH v2] t5562: do not reuse output files

2018-11-23 Thread Max Kirillov
occasional failures of the test script. Avoid the issue by unlinking the older files before writing to them. Reported-by: Carlo Arenas Helped-by: Carlo Arenas Helped-by: Junio C Hamano Signed-off-by: Max Kirillov --- Thanks. Updated t/t5562-http-backend-content-length.sh | 2 ++ 1 file changed

[PATCH] t5562: do not reuse output files

2018-11-23 Thread Max Kirillov
failures of the test script. Avoid the issue by unlinking the older files before writing to them. Reported-by: Carlo Arenas Helped-by: Carlo Arenas Signed-off-by: Max Kirillov --- Thanks for the analysis. I seem to have guessed the reason. This patch should prevent it. I think the tests

Re: [PATCH] t5562: skip if NO_CURL is enabled

2018-11-22 Thread Max Kirillov
On Thu, Nov 22, 2018 at 11:17:22AM -0500, Jeff King wrote: > The script I use is at: > > https://github.com/peff/git/blob/meta/stress > > which you invoke like "/path/to/stress t5562" from the top-level of a > git.git checkout. It basically just runs a loop of twice as many > simultaneous

[PATCH] t5562: fix perl path

2018-11-22 Thread Max Kirillov
From: Jeff King Some systems do not have perl installed to /usr/bin. Use the variable from the build settiings, and call perl directly than via shebang. Signed-off-by: Max Kirillov --- Submitting. Could you sign-off? Also removed shebang from the script as it is not needed t/t5562-http

Re: [PATCH] t5562: skip if NO_CURL is enabled

2018-11-21 Thread Max Kirillov
On Wed, Nov 21, 2018 at 05:04:25PM -0800, Carlo Arenas wrote: > the error that gets eventually to stderr in the caller comes from > get_packet_data, who is trying to read 4 bytes and gets 0. > when looking at the trace (obtained with ktrace) Yes too early close of the input data is the thing

Re: [PATCH] t5562: skip if NO_CURL is enabled

2018-11-21 Thread Max Kirillov
On Wed, Nov 21, 2018 at 04:02:04AM -0800, Carlo Arenas wrote: > for some tracing, it would seem that it gets 0 when > trying to read 4 bytes from what I think is a pipe that connects to a > child that has been gone already for a while. Could you clarify it? I'm afraid I don't understand.

Re: [PATCH] t5562: skip if NO_CURL is enabled

2018-11-19 Thread Max Kirillov
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote: > NO_CURL reflects the build setting (for http support); CURL checks for > the curl binary, but as Ævar points out the requirements must be from > somewhere else since a NO_CURL=1 build (tested in macOS) still passes > the test, but not

Re: [PATCH] t5562: skip if NO_CURL is enabled

2018-11-19 Thread Max Kirillov
On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote: > 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack", > 2018-07-27) > introduced all tests but without a check for CURL support from git. The tests should not be using curl, they just pipe data to

[PATCH v2] http-backend test: make empty CONTENT_LENGTH test more realistic

2018-09-11 Thread Max Kirillov
This is a test of smart HTTP, so it should use the smart HTTP endpoints (e.g. /info/refs?service=git-receive-pack), not dumb HTTP (HEAD). Signed-off-by: Jonathan Nieder Signed-off-by: Max Kirillov --- > do you know why the test passes without 574c513e8d (http-backend: allow >

[PATCH] http-backend: Treat empty CONTENT_LENGTH as zero

2018-09-10 Thread Max Kirillov
there is no practical difference, as the GET request where it can be empty is handled without actual reading the body (in get_info_refs() function), but it is better to stick to the correct behavior. Signed-off-by: Max Kirillov --- The incremental. Hopefully I described the reason right. Needs "signed-off-by&q

Re: [PATCH v3] http-backend: allow empty CONTENT_LENGTH

2018-09-10 Thread Max Kirillov
On Sun, Sep 09, 2018 at 10:17:48PM -0700, Jonathan Nieder wrote: > From: Max Kirillov > Subject: http-backend test: make empty CONTENT_LENGTH test more realistic Thank you, yes, this is what should have left

Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

2018-09-08 Thread Max Kirillov
On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote: > In any case, hopefully we can fix this before the final, as this is > a regression introduced during this cycle? I think I am going to stop at the v4. Unless there are some corrections requested.

[PATCH v4] http-backend: allow empty CONTENT_LENGTH

2018-09-08 Thread Max Kirillov
ENT_LENGTH to be treated as zero-length body is expected, as specified by RFC3875. It does not actually matter what does it mean because body is never read anyway, it just should not cause parse error. Add a test for the case. Reported-By: Jelmer Vernooij Authored-by: Jeff King Signed-off-by: Ma

[PATCH v2] http-backend: allow empty CONTENT_LENGTH

2018-09-07 Thread Max Kirillov
TH to also be treated as "read until EOF". It does not actually matter what does it mean because body is never read anyway, it just should not cause parse error. Add a test for the case. Reported-By: Jelmer Vernooij Signed-off-by: Max Kirillov --- Provided more thorough message, a

[PATCH v3] http-backend: allow empty CONTENT_LENGTH

2018-09-07 Thread Max Kirillov
TH to also be treated as "read until EOF". It does not actually matter what does it mean because body is never read anyway, it just should not cause parse error. Add a test for the case. Reported-By: Jelmer Vernooij Signed-off-by: Max Kirillov --- Provided more thorough message, a

Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

2018-09-07 Thread Max Kirillov
On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote: > Max Kirillov writes: > >> Actually, another reason for the latest issue was that CONTENT_LENGTH >> is parsed for GET requests at all. It should be parsed only for POST >> requests, or, rather, only for upo

Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

2018-09-06 Thread Max Kirillov
Actually, another reason for the latest issue was that CONTENT_LENGTH is parsed for GET requests at all. It should be parsed only for POST requests, or, rather, only for upoad-pack and receive-pack requests.

Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

2018-09-06 Thread Max Kirillov
On Thu, Sep 06, 2018 at 11:38:31PM -0400, Jeff King wrote: > My understanding from Jelmer's report is that a present-but-empty > variable should be counted as "0" to mean "do not read any body bytes". > That matches my reading of RFC 3875, which says: > > If no data is attached, then NULL (or

[PATCH v2] http-backend: allow empty CONTENT_LENGTH

2018-09-06 Thread Max Kirillov
POSTs" from t5551 starts faliing, if unset or empty CONTENT_LENGTH is treated as zero length body. So keep the existing behavior as much as possible. Add a test for the case. Reported-By: Jelmer Vernooij Signed-off-by: Max Kirillov --- Added the "reported-by" and explained inlin

Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

2018-09-06 Thread Max Kirillov
On Thu, Sep 06, 2018 at 02:54:18PM -0700, Junio C Hamano wrote: > Max Kirillov writes: >> This should fix it. I'm not sure should it treat it as 0 or "-1" >> At least the tests mentioned by Jeff fails if I try to treat missing >> CONTENT_LENGTH as "-1"

[PATCH] http-backend: allow empty CONTENT_LENGTH

2018-09-06 Thread Max Kirillov
. Add a test for the case. [1] https://public-inbox.org/git/20160329201349.gb9...@sigill.intra.peff.net/ Signed-off-by: Max Kirillov --- Hi. This should fix it. I'm not sure should it treat it as 0 or "-1" At least the tests mentioned by Jeff fails if I try to treat missing CONT

Re: [PATCH v9 2/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-08-04 Thread Max Kirillov
On Sat, Aug 04, 2018 at 08:34:08AM +0200, Duy Nguyen wrote: > On Fri, Jul 27, 2018 at 5:50 AM Max Kirillov wrote: >> + if (max_request_buffer < req_len) { >> + die("request was larger than our maximum size (%lu): " >> +

Re: [PATCH] t5562: avoid non-portable "export FOO=bar" construct

2018-07-29 Thread Max Kirillov
> Commit 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack", 2018-07-27) adds a test which uses the non-portable export construct. Replace it with "FOO=bar && export FOO" instead. Thank you. Apparently the check is performed by make -C t, and I did not run it like this since I

Re: [PATCH v9 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-07-26 Thread Max Kirillov
Only the 3rd patch has changed

[PATCH v9 3/3] http-backend: respect CONTENT_LENGTH for receive-pack

2018-07-26 Thread Max Kirillov
is specified to a value which does not fit into ssize_t. Helped-by: Junio C Hamano Signed-off-by: Max Kirillov --- help.c | 1 + http-backend.c | 32 - t/t5562-http-backend-content-length.sh | 155 + t/t5562/invoke

[PATCH v9 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-07-26 Thread Max Kirillov
* fix the gzip usage as suggested in https://public-inbox.org/git/xmqqk1quvegh@gitster-ct.c.googlers.com/ * better explanation of why status check is needed * redirect only the helper call, not the whole shell function, also move more into the shell function Max Kirillov (3): http-backend

[PATCH v9 2/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-07-26 Thread Max Kirillov
Hamano Signed-off-by: Max Kirillov Signed-off-by: Junio C Hamano --- config.c | 2 +- config.h | 1 + http-backend.c | 54 +++--- 3 files changed, 49 insertions(+), 8 deletions(-) diff --git a/config.c b/config.c index fbbf0f8e9f

[PATCH v9 1/3] http-backend: cleanup writing to child process

2018-07-26 Thread Max Kirillov
-off-by: Max Kirillov Signed-off-by: Junio C Hamano --- http-backend.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/http-backend.c b/http-backend.c index adaef16fad..cefdfd6fc6 100644 --- a/http-backend.c +++ b/http-backend.c @@ -279,6 +279,12 @@ static

Re: [PATCH v8 3/3] http-backend: respect CONTENT_LENGTH for receive-pack

2018-07-25 Thread Max Kirillov
On Wed, Jul 25, 2018 at 08:41:31PM +0200, SZEDER Gábor wrote: > On Wed, Jul 25, 2018 at 4:51 PM Max Kirillov wrote: >>> I just happened to stumble upon a failure because of 'fatal: the >>> remote end hung up unexpectedly' in the test 'push plain'. >> >&g

Re: [PATCH v8 3/3] http-backend: respect CONTENT_LENGTH for receive-pack

2018-07-25 Thread Max Kirillov
On Wed, Jul 25, 2018 at 02:14:35PM +0200, SZEDER Gábor wrote: >> +# sometimes there is fatal error buit the result is still 200 > > s/buit/but/ Thanks, will fix >> +if grep 'fatal:' act.err >> +then >> +return 1 >> +fi > > I just happened to stumble upon a failure

[PATCH v2] unpack-trees: do not fail reset because of unmerged skipped entry

2018-07-10 Thread Max Kirillov
n [1], the up-to-date checker mistakenly treats conflicted entry which does not exist in HEAD as still skipped by sparse checkout. Use the fix suggested in [1]. Also, add test case which verifies the issue is fixed. [1] https://public-inbox.org/git/20180616051444.ga29...@duynguyen.home/ Fix-aut

Re: [PATCH] unpack-trees: do not fail reset because of unmerged skipped entry

2018-07-10 Thread Max Kirillov
On Fri, Jun 15, 2018 at 12:58:40PM -0700, Junio C Hamano wrote: > Do we want to verify the state after the 'hard' reset succeeds as > well? Things like > > - all paths in the HEAD and all paths in the index are identical; > > - paths that do exist in the working tree are all identical to

Re: [PATCH] unpack-trees: do not fail reset because of unmerged skipped entry

2018-07-10 Thread Max Kirillov
On Sat, Jun 16, 2018 at 07:14:44AM +0200, Duy Nguyen wrote: > -- 8< -- > diff --git a/unpack-trees.c b/unpack-trees.c > index 3a85a02a77..eb544ee1b3 100644 > --- a/unpack-trees.c > +++ b/unpack-trees.c > @@ -1246,7 +1246,7 @@ static void mark_new_skip_worktree(struct exclude_list > *el, >

Re: [PATCH] unpack-trees: do not fail reset because of unmerged skipped entry

2018-06-16 Thread Max Kirillov
> I do not know offhand if "reset --merge" should force succeeding in such a case, but I agree that it is criminal to stop "reset --hard" with "not uptodate", as the whole point of "hard reset" is to get rid of the 'not up-to-date' modification. I originally had a fix just for "reset --hard". It

[PATCH] unpack-trees: do not fail reset because of unmerged skipped entry

2018-06-14 Thread Max Kirillov
nflicted entries before performing reset. Also, add test case which verifies the issue is fixed. Signed-off-by: Max Kirillov --- I have tried to use sparse-checkout for merging and cherrypicking, to save on IO and disk space. It works, mostly, but there are issues here and there. This one was low hang

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

2018-06-10 Thread Max Kirillov
On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote: > On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote: >> +env \ >> +CONTENT_TYPE=application/x-git-upload-pack-request \ >> +QUERY_STRING=/repo.git/git-upload-pack \ >> +

[PATCH v8 2/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-06-10 Thread Max Kirillov
Hamano Signed-off-by: Max Kirillov --- config.c | 2 +- config.h | 1 + http-backend.c | 54 +++--- 3 files changed, 49 insertions(+), 8 deletions(-) diff --git a/config.c b/config.c index c698988f5e..4148a3529d 100644 --- a/config.c

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

2018-06-10 Thread Max Kirillov
On Tue, Jun 05, 2018 at 01:18:08AM +0300, Max Kirillov wrote: > On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote: >> Since this is slightly less efficient, and because it only matters if >> the web server does not already close the pipe, should this have a >> run-ti

[PATCH v8 1/3] http-backend: cleanup writing to child process

2018-06-10 Thread Max Kirillov
-off-by: Max Kirillov --- http-backend.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/http-backend.c b/http-backend.c index 88d2a9bc40..206dc28e07 100644 --- a/http-backend.c +++ b/http-backend.c @@ -278,6 +278,12 @@ static struct rpc_service *select_service

[PATCH v8 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-06-10 Thread Max Kirillov
Did the fixes proposed for v7 Max Kirillov (3): http-backend: cleanup writing to child process http-backend: respect CONTENT_LENGTH as specified by rfc3875 http-backend: respect CONTENT_LENGTH for receive-pack config.c | 2 +- config.h

[PATCH v8 3/3] http-backend: respect CONTENT_LENGTH for receive-pack

2018-06-10 Thread Max Kirillov
is specified to a value which does not fit into ssize_t. Helped-by: Junio C Hamano Signed-off-by: Max Kirillov --- help.c | 1 + http-backend.c | 32 - t/t5562-http-backend-content-length.sh | 169 + t/t5562/invoke

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

2018-06-04 Thread Max Kirillov
On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote: Thanks for the comments, I will do the things you proposed, or try to and get back later if there are any issues. Some notes below. > On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote: > Since this is slightly less eff

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

2018-06-04 Thread Max Kirillov
On Mon, Jun 04, 2018 at 01:31:58PM +0900, Junio C Hamano wrote: > Max Kirillov writes: >> +size_t n = xread(0, buf, chunk_length); >> +if (n < 0) >> +die_errno("Reading request failed"); > > n that is of type s

[PATCH v7 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-06-02 Thread Max Kirillov
the complications pointed out by Jeff, it just filters the input in the frontend process. I hope it is acceptable thing to do. Max Kirillov (2): http-backend: respect CONTENT_LENGTH as specified by rfc3875 http-backend: respect CONTENT_LENGTH for receive-pack Makefile

[PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

2018-06-02 Thread Max Kirillov
is specified to a value which does not fit into ssize_t. Helped-by: Junio C Hamano Signed-off-by: Max Kirillov --- Makefile| 1 + http-backend.c | 49 ++-- t/helper/test-print-larger-than-ssize.c | 11 ++ t/helper/test-tool.c

[PATCH v7 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-06-02 Thread Max Kirillov
to support chunked transfer-encoding. Signed-off-by: Florian Manschwetus [mk: fixed trivial build failures and polished style issues] Helped-by: Junio C Hamano Signed-off-by: Max Kirillov --- config.c | 2 +- config.h | 1 + http-backend.c | 43

Re: [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-12-19 Thread Max Kirillov
On Tue, Dec 19, 2017 at 02:13:33PM -0800, Junio C Hamano wrote: > So... is there going to be an update (or has there been one and I > missed it)? Yes there it! I wanted to add tests for the cases Jeff mentioned. It is almost done, I just need to check I did not miss some note.

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

2017-11-28 Thread Max Kirillov
On Tue, Nov 28, 2017 at 10:26:33PM -0500, Jeff King wrote: > On Mon, Nov 27, 2017 at 12:40:51AM +0200, Max Kirillov wrote: > That said, we already have some precedent in "git version > --build-options" to report sizes there. Can we do something like the > patch below instea

Re: [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-28 Thread Max Kirillov
On Mon, Nov 27, 2017 at 01:02:10PM +0900, Junio C Hamano wrote: > To recap (other than the typofix in the proposed log message), here > is what I would have as SQUASH??? on top of (or interspersed with) > v6. Thank you. I'll update it a bit later. May/should I add "Signed-off-by:" from you?

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

2017-11-26 Thread Max Kirillov
On Sun, Nov 26, 2017 at 05:18:55PM -0500, Eric Sunshine wrote: > On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov <m...@max630.net> wrote: >> +int cmd_main(int argc, const char **argv) >> +{ >> + if (argc == 2 && strcmp(argv[1], "(size_t)(-20)") ==

Re: [PATCH v5 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-26 Thread Max Kirillov
On Sun, Nov 26, 2017 at 06:38:06PM +0900, Junio C Hamano wrote: > Max Kirillov <m...@max630.net> writes: >> +static ssize_t env_content_length() > > We need s/length()/length(void)/; though. thanks, fixed it

[PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-26 Thread Max Kirillov
v6: Do not implement generic git_env_ssize_t(), instead export git_parse_ssize_t() from config.c and hardcode the rest. Florian Manschwetus (1): http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov (1): t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

[PATCH v6 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-26 Thread Max Kirillov
ial build failures and polished style issues] Signed-off-by: Max Kirillov <m...@max630.net> --- config.c | 2 +- config.h | 1 + http-backend.c | 50 +- 3 files changed, 51 insertions(+), 2 deletions(-) diff --git a/config.c b/c

[PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

2017-11-26 Thread Max Kirillov
is specified to a value which does not fix into ssize_t. Signed-off-by: Max Kirillov <m...@max630.net> --- Makefile | 1 + t/helper/test-print-values.c | 10 ++ t/t5560-http-backend-noserver.sh | 30 ++ 3 files changed, 41 inse

Re: [PATCH v5 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-26 Thread Max Kirillov
On Sun, Nov 26, 2017 at 12:46:12PM +0900, Junio C Hamano wrote: > Max Kirillov <m...@max630.net> writes: > > +ssize_t git_env_ssize_t(const char *k, ssize_t val) > > +{ > > + const char *v = getenv(k); > > + if (v && !git_parse_ssize_t(v, )) &g

Re: [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
On Fri, Nov 24, 2017 at 02:54:50PM +0900, Junio C Hamano wrote: > Max Kirillov <m...@max630.net> writes: >> I hope I marked it correctly in the trailers. > > It is probably more conventional to do it like so: > > From: Florian Manschwetus <manschwe...@c

[PATCH v4 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
to support chunked transfer-encoding. Signed-off-by: Florian Manschwetus <manschwe...@cs-software-gmbh.de> [mk: fixed trivial build failures and polished style issues] Signed-off-by: Max Kirillov <m...@max630.net> --- config.c | 8 config.h | 1 + http-ba

[PATCH v5 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

2017-11-25 Thread Max Kirillov
is specified to a value which does not fix into ssize_t. Signed-off-by: Max Kirillov <m...@max630.net> --- Makefile | 1 + t/helper/test-print-values.c | 10 ++ t/t5560-http-backend-noserver.sh | 30 ++ 3 files changed, 41 inse

[PATCH v4 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
* polished style * add tests * marked the authorship more correctly Max Kirillov (2): http-backend: respect CONTENT_LENGTH as specified by rfc3875 t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases Makefile | 1 + config.c | 8

[PATCH v5 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
input until EOF. If the variable is not defined, keep older behavior of reading until EOF because it is used to support chunked transfer-encoding. Signed-off-by: Florian Manschwetus <manschwe...@cs-software-gmbh.de> [mk: fixed trivial build failures and polished style issues] Signed-off-by: Max

[PATCH v5 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
I seem to forgot to put the authorship lines, and also did something with replies, so sending another sequence. v5: * marked the authorship more correctly v4: * polished style * add tests Max Kirillov (2): http-backend: respect CONTENT_LENGTH as specified by rfc3875 t5560-http-backend

[PATCH v4 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

2017-11-25 Thread Max Kirillov
is specified to a value which does not fix into ssize_t. Signed-off-by: Max Kirillov <m...@max630.net> --- Makefile | 1 + t/helper/test-print-values.c | 10 ++ t/t5560-http-backend-noserver.sh | 30 ++ 3 files changed, 41 inse

Re: [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
On Sat, Nov 25, 2017 at 07:38:33PM -0500, Eric Sunshine wrote: > On Sat, Nov 25, 2017 at 4:47 PM, Max Kirillov <m...@max630.net> wrote: >> On Thu, Nov 23, 2017 at 08:30:39PM -0500, Eric Sunshine wrote: >>>> +static ssize_t read_request_fix_len(int fd, size_t req_len

Re: [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-25 Thread Max Kirillov
Thanks for the review. I saw only reaction of the Jeff in the original thread and though that it is ok otherwise. I'm fixing the things you mentioned. On Thu, Nov 23, 2017 at 08:30:39PM -0500, Eric Sunshine wrote: >> +static ssize_t read_request_fix_len(int fd, size_t req_len, unsigned char >>

[PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2017-11-23 Thread Max Kirillov
de> Fixed-by: Max Kirillov <m...@max630.net> Signed-off-by: Max Kirillov <m...@max630.net> --- Hi I came across this issue, and I think is should be good to restore the patch. It is basically same but I squashed them, fixed the thing you mentioned and also some trivial buil

Re: [PATCH] gitk: expand $config_file_tmp before reporting to user

2017-09-28 Thread Max Kirillov
On Thu, Sep 28, 2017 at 02:31:17PM +0200, Johannes Schindelin wrote: >>> Max Kirillov <m...@max630.net> writes: >>>> Tilda-based path may confise some users. First, tilda is not known >>>> for Window users, second, it may point to unexpected location >

[PATCH] gitk: expand $config_file_tmp before reporting to user

2017-09-27 Thread Max Kirillov
p", for example. It should be less cryptic Signed-off-by: Max Kirillov <m...@max630.net> --- gitk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gitk b/gitk index 877d49e1de..48c1d3e714 100755 --- a/gitk +++ b/gitk @@ -2844,7 +2844,8 @@ proc config_ch

[PATCH v2] describe: teach --match to handle branches and remotes

2017-09-19 Thread Max Kirillov
and add tests. Signed-off-by: Max Kirillov <m...@max630.net> --- Changed to use skip_prefix(). Calculate path_to_match only once. Add case of discarding unknown type with exclude Documentation/git-describe.txt | 24 ++-- builtin/describe.c

Re: [PATCH] describe: teach --match to handle branches and remotes

2017-09-19 Thread Max Kirillov
On Tue, Sep 19, 2017 at 08:52:24AM +0900, Junio C Hamano wrote: > I think you can use skip_prefix() to avoid counting the length of > the prefix yourself, i.e. Thanks, will use it. > The hardcoded +10 for "is_tag" case assumes that anything other than > "refs/tags/something" would ever be used

[PATCH] describe: teach --match to handle branches and remotes

2017-09-17 Thread Max Kirillov
and add tests. Signed-off-by: Max Kirillov <m...@max630.net> --- Requires https://public-inbox.org/git/20170916055344.31866-1-...@max630.net/ This extends --match to branches and remote-tracking references. It is in some respect regression, if anybody have used --all and --match together this

[PATCH] describe: fix matching to actually match all patterns

2017-09-16 Thread Max Kirillov
`git describe --match` with multiple patterns matches only first pattern. If it fails, next patterns are not tried. Fix it, add test cases and update existing test which has wrong expectation. Signed-off-by: Max Kirillov <m...@max630.net> --- builtin/describe.c | 9 ++--- t

[PATCH] gitk: blame older file in case of copied and renamed files

2017-03-09 Thread Max Kirillov
ould use the older one. Since ctext_file_names in diff mode only used for parent commit filenames, there is no need to split it to 2 lists, just change its so that for diff mode it means older filename always. Signed-off-by: Max Kirillov <m...@max630.net> --- gitk | 19 +-- 1 file ch

Re: [BUG/RFC] Git Gui: GIT_DIR leaks to spawned Git Bash

2017-01-17 Thread Max Kirillov
On Tue, Jan 17, 2017 at 11:52:29AM +0100, Johannes Schindelin wrote: > Hi Max, > > On Tue, 17 Jan 2017, Max Kirillov wrote: > >> Apparently various GIT_* environment variables (most >> interesting is GIT_DIR but AFAIR there were more) leak to >> shell session lau

[BUG/RFC] Git Gui: GIT_DIR leaks to spawned Git Bash

2017-01-16 Thread Max Kirillov
Hello. Apparently various GIT_* environment variables (most interesting is GIT_DIR but AFAIR there were more) leak to shell session launched from Git Gui's "Git Bash" menu item. Which can cause unexpected results if user navigates in that shell to some other repository (in can also include

Re: [PATCH] mingw: consider that UNICODE_STRING::Length counts bytes

2016-12-19 Thread Max Kirillov
On Mon, Dec 19, 2016 at 01:57:29PM -0800, Junio C Hamano wrote: > Max, I see this is a resend from a few days ago Sorry about resend. For some reason I don't get the list copy (might be some clever duplicate elimination in my forwardings), and marc.info seems to be slow to update, so I had no

[PATCH] mingw: consider that UNICODE_STRING::Length counts bytes

2016-12-19 Thread Max Kirillov
UNICODE_STRING::Length field means size of buffer in bytes[1], despite of buffer itself being array of wchar_t. Because of that terminating zero is placed twice as far. Fix it. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380518.aspx Signed-off-by: Max Kirillov <m...@max630.

[PATCH] mingw: consider that UNICODE_STRING::Length counts bytes

2016-12-17 Thread Max Kirillov
UNICODE_STRING::Length field means size of buffer in bytes[1], despite of buffer itself being array of wchar_t. Because of that terminating zero is placed twice as far. Fix it. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380518.aspx Signed-off-by: Max Kirillov <m...@max630.

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

2016-07-26 Thread Max Kirillov
Hi. On Wed, Jul 20, 2016 at 07:24:18PM +0200, Nguyễn Thái Ngọc Duy wrote: > + - `remote.*` added by submodules may be per working directory as > + well, unless you are sure remotes from all possible submodules in > + history are consistent. ... > @@ -1114,7 +1114,7 @@ cmd_sync() >

Re: [ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase

2016-03-29 Thread Max Kirillov
On Tue, Mar 29, 2016 at 09:29:45PM -0400, Trevor Saunders wrote: > hm how? the workflow you use locally has basically nothingto do with how > pushes work. I work on several projects daily where everyone pushes to > trunk, but locally I use branches. You just need to fetch rebase then > either

[ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase

2016-03-28 Thread Max Kirillov
Hello. I would like to announce git-push-update, a tool which emulates server-side merge or rebase. The link: https://github.com/max630/git-push-update It is a bash script which fetches latest remote branch, creates temporary clone, performs there merge or rebase, pushes results to server. If

Re: [PATCH v3 6/6] worktree add: switch to worktree version 1

2016-02-01 Thread Max Kirillov
On Mon, Feb 01, 2016 at 01:05:05PM +0700, Duy Nguyen wrote: > On Mon, Feb 1, 2016 at 12:33 PM, Max Kirillov <m...@max630.net> wrote: >> 1. For submodules (which must be left per-worktree) this >> approach is not going to work, because you don't know all >> variables

Re: [PATCH v3 6/6] worktree add: switch to worktree version 1

2016-01-31 Thread Max Kirillov
On Tue, Jan 26, 2016 at 06:44:45PM +0700, Nguyễn Thái Ngọc Duy wrote: > + for (key_p = per_wortree_keys; *key_p; key_p++) { > + const char *key = *key_p; > + char *value = get_key(sb.buf, key); > + > + if (value) { > +

Re: [PATCH v3 1/6] worktree: new repo extension to manage worktree behaviors

2016-01-30 Thread Max Kirillov
On Wed, Jan 27, 2016 at 02:12:52PM -0800, Junio C Hamano wrote: > More seriously, are we confident that the overall worktree support > is mature enough by now that once we add an experimental feature X > at version 1, we can promise to keep maintaining it forever at > version N for any positive

Re: [PATCH v3 1/6] worktree: new repo extension to manage worktree behaviors

2016-01-30 Thread Max Kirillov
On Tue, Jan 26, 2016 at 06:44:40PM +0700, Nguyễn Thái Ngọc Duy wrote: > +WORKTREE VERSIONS AND MIGRATION > +--- > +Multiple worktree is still an experimental feature and evolving. Every > +time the behavior is changed, the "worktree version" is stepped > +up. Worktree

Re: [PATCH v3 2/6] path.c: new (identical) list for worktree v1

2016-01-30 Thread Max Kirillov
On Tue, Jan 26, 2016 at 06:44:41PM +0700, Nguyễn Thái Ngọc Duy wrote: > Worktree v1 may have different .git file split than v0. Add support > code to change common file list based on extensions.worktree. The list > for now is identical to v0. In the end this turned out to be needed only for

Re: [PATCH v3 5/6] config: select .git/common/config with --repo

2016-01-30 Thread Max Kirillov
On Tue, Jan 26, 2016 at 06:44:44PM +0700, Nguyễn Thái Ngọc Duy wrote: > This new option allows the user to write to or read from > .git/common/config in worktree v1. In worktree v0, --repo is an alias > of --local. Looks like by default a value is always set in a local config, which might be

Re: [PATCH 0/5] Split .git/config in multiple worktree setup

2015-12-03 Thread Max Kirillov
On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote: > On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov <m...@max630.net> wrote: >> Using builtin defaults might be confusing for users - >> editing the info/config.worktree they must keep in mind the >> list of default

Re: [PATCH 0/5] Split .git/config in multiple worktree setup

2015-12-03 Thread Max Kirillov
On Thu, Dec 03, 2015 at 11:52:43AM -0800, Junio C Hamano wrote: > I actually prefer *not* to have any configurability > to avoid confusion between users. This could be an approach. But because of upgrade issues which I described in the other response it looks like this decision is not easy to

Re: [PATCH 0/5] Split .git/config in multiple worktree setup

2015-12-02 Thread Max Kirillov
On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote: > Let's restart this. From the last discussion [1], we need to make > core.worktree per-worktree for submodules to work. We also need > core.sparseCheckout per-worktree. Thank you. It would be nice to have it, so that features

Re: What's cooking in git.git (Nov 2015, #03; Fri, 20)

2015-11-24 Thread Max Kirillov
On Fri, Nov 20, 2015 at 09:09:37AM -0500, Jeff King wrote: > * mk/blame-first-parent (2015-11-20) 1 commit > - blame: fix object casting regression > > Regression fix for a topic already in master. > > Will merge to 'next'. You mistyped my name in the commit message of 044e0ad679 :) -- To

Re: [PATCH] blame: add test case for using tag object as a final ref

2015-11-18 Thread Max Kirillov
On Wed, Nov 18, 2015 at 8:00 AM, Jeff King <p...@peff.net> wrote: > On Wed, Nov 18, 2015 at 07:36:32AM +0200, Max Kirillov wrote: > >> It was discovered [1] that 1b0d4a broke blaming starting from tag object. >> Add test which verifies such blaming works. >&g

[PATCH] blame: add test case for using tag object as a final ref

2015-11-17 Thread Max Kirillov
It was discovered [1] that 1b0d4a broke blaming starting from tag object. Add test which verifies such blaming works. [1] http://mid.gmane.org/20151117224809.ge27...@sigill.intra.peff.net Signed-off-by: Max Kirillov <m...@max630.net> --- Thank you. Sorry, I should have noticed that obj

[PATCH v5 2/3] blame: extract find_single_final

2015-10-29 Thread Max Kirillov
Signed-off-by: Max Kirillov <m...@max630.net> --- builtin/blame.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index 295ce92..38f6267 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -2401,16 +2

[PATCH v5 0/3] blame: allow blame --reverse --first-parent when it makes sense

2015-10-29 Thread Max Kirillov
Update the test: * Fix style notes in tests * Remove the non-first-parent case, because it's more like fature request, and is not fixed in this batch * Rewrite the commit message, hopely now it answers better to "why" Max Kirillov (3): blame: add test to describe use of blame --rever

[PATCH v5 1/3] blame: test to describe use of blame --reverse --first-parent

2015-10-29 Thread Max Kirillov
describes the expected behavior of `blame --reverse --first-parent` in the case described above. Signed-off-by: Max Kirillov <m...@max630.net> --- t/t8009-blame-vs-topicbranches.sh | 36 1 file changed, 36 insertions(+) create mode 100755 t/t8009-bl

  1   2   3   4   >