On Wed, Feb 13, 2019 at 11:56:16AM +0100, SZEDER Gábor wrote:
>>> + if (iter)
>>> + {
>
> According to our CodingGuidelines, the opening bracket should go on
> the same line as the condition, i.e.
>
> if (iter) {
Oh, thanks. I must have been professionally deformed.
On Wed, Feb 13, 2019 at 11:08:01AM +0100, Ævar Arnfjörð Bjarmason wrote:
> You have an extra two whitespaces after "&&" there.
Thanks, will check it.
>> +git commit --allow-empty -m commit &&
> Looks like just "test_commit A" would do here.
About this I'm not sure. AFAIK test_commit does lot
On Tue, Feb 19, 2019 at 10:15:36PM +0200, Max Kirillov wrote:
> expecially at
> Windows where you cannot just unlink busy file and reuse its
> place in directory
It was at Linux actually. Well, whatever the rename feels more
sure thing to me.
On Mon, Feb 18, 2019 at 10:57:13PM +0100, Johannes Schindelin wrote:
> I have to take that assessment back. So sad.
>
> After that build, I cherry-picked the commit on top of shears/pu (which is
> Git for Windows' ever-green branch that continuously rebases Git for
> Windows' `master` onto git.git
On Mon, Feb 18, 2019 at 10:06:21PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> But in our attempt to exit(), we try to "cleanup children" and that
>> is what gets stuck.
>
> I have not paid enough attention to this thread to say if this is dumb,
> but just in case it's useful. For this class of probl
On Mon, Feb 18, 2019 at 03:54:27PM -0500, Randall S. Becker wrote:
> On February 18, 2019 15:50, Max Kirillov wrote:
> > To: SZEDER Gábor ; git@vger.kernel.org
> > Cc: Max Kirillov ; Johannes Schindelin
> > ; Randall S. Becker
> > ; 'Junio C Hamano'
> &g
On Mon, Feb 18, 2019 at 03:46:34PM -0500, Randall S. Becker wrote:
> On February 18, 2019 15:41, Johannes Schindelin wrote:
> > So could you try with this patch?
> >
> > -- snipsnap --
> > diff --git a/http-backend.c b/http-backend.c index d5cea0329a..7c1b4a2555
> > 100644
> > --- a/http-backend.c
: SZEDER Gábor
Signed-off-by: Max Kirillov
---
Submitting as proper patch. Note: I believe it does not relate to other issues
discussed in this thread.
t/t5562/invoke-with-content-length.pl | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/t5562/invoke-with-content
On Sat, Feb 16, 2019 at 10:57:52AM -0800, Junio C Hamano wrote:
> I'm inclined to
>
> - keep b46221ff in 'master', not reverted.
from the branch, cc95bc2025 "t5562: replace /dev/zero with a
pipe from generate_zero_bytes" could be replaced with [1]
"t5562: do not depend on /dev/zero", for simplic
On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote:
> Sadly, the fix does not change the results. In fact, it
> makes the hang far more likely. Subtest 6,7,8 fails here,
> at close()
Correct, I did not expect it to help, it was for the other
issue.
As for the hang issue, from your
On Fri, Feb 15, 2019 at 02:02:13PM +0100, SZEDER Gábor wrote:
> I haven't yet seen that hang in the wild and couldn't reproduce it on
> purpose, but there is definitely something fishy with t5562 even on
> Linux and even without that perl generate_zero_bytes helper.
>
> It won't show most of the p
be even safer than providing some
meaningless data.
Replace /dev/zero with /dev/null to avoid issues with platforms which do
not have /dev/zero.
[1]
https://public-inbox.org/git/20190209185930.5256-4-randall.s.bec...@rogers.com/
Reported-by: Randall S. Becker
Signed-off-by: Max Kirillov
---
By
On Thu, Feb 14, 2019 at 06:33:56PM -0500, Randall S. Becker wrote:
> Here is the full set of traces (from subtest 6, which just hung). There are
> no I/O errors reported on any pipe or file descriptor. There is one git
> process waiting for a read to occur but no one is doing any writing. Most
> pr
On Thu, Feb 14, 2019 at 05:17:26PM -0500, Randall S. Becker wrote:
> Unfortunately, subtest 13 still hangs on NonStop, even
> with this patch, so our Pipeline still hangs. I'm glad
> it's better on Azure, but I don't think this actually
> addresses the root cause of the hang. This is now the
> four
On Wed, Feb 13, 2019 at 10:16:26AM -0500, randall.s.bec...@rogers.com wrote:
> On 2019-02-13, Max Kirillov, wrote:
> As far as the unintended reuse of the output file, and issues with pipes,
> yes, the NonStop is very sensitive to complex use of pipes and much of the
> compatibility is
On Mon, Feb 11, 2019 at 11:59:00AM -0500, Randall S. Becker wrote:
> Hi All,
>
> I have localized the hang in t5562 (previous thread) to the
> invoke-with-content-length.pl script.
Hi.
I have not noticed the previous thread.
I have yet to look at it more closely, but there have been
one case of
On Fri, Feb 08, 2019 at 04:40:28PM -0500, Eric Sunshine wrote:
> The call to strbuf_init() is leaking the allocated strbuf buffer each
> time through the loop. The typical way to re-use a strbuf, and the way
> you should do it here, is strbuf_reset().
Thank you! Will fix it
On Mon, Feb 11, 2019 at 08:24:46PM +0100, Michael Haggerty wrote:
> The change to `write_with_updates()` doesn't only affect `pack-refs`.
> That function is also called when the `packed-refs` file has to be
> rewritten when a packed reference is deleted. This is another thing
> that you could test.
failing
pack-refs command - the one which would not suffer performance penalty
to verify the sortedness - when it encounters not really sorted existing
data.
Signed-off-by: Max Kirillov
---
Fixed the notes
refs/packed-backend.c | 18 ++
t/t3212-pack-refs-broken-sorting.sh
On Wed, Jan 30, 2019 at 06:31:34PM -0500, Eric Sunshine wrote:
> On Wed, Jan 30, 2019 at 6:21 PM Max Kirillov wrote:
>> + strbuf_addf(err, "broken sorting in
>> packed-refs: '%s' > '%s'",
>> +
penalty
to verify the sortedness - when it encounters not really sorted existing
data.
Signed-off-by: Max Kirillov
---
I happened to have a not really sorted packed-refs file. As you might guess,
it was quite wtf-ing experience. It worked, mostly, but there was one branch
which just did not resolve
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 exte
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 it
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 ru
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
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
>
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
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
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 invo
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
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 which
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.
Meanwhil
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
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
http-ba
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
>
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
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
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.
NGTH 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: Max Kirillo
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, also
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, also
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
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.
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 un
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
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&quo
.
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
CO
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): "
>> +
> 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 onl
Only the 3rd patch has changed
TH 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/i
-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
* 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
y: Junio C 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
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
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 be
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
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 HEAD
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,
>
> 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 w
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
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 \
>> +
y: Junio C 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
---
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
-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
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
TH 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/i
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
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
g 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
Mak
TH 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-t
it is used 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-back
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.
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
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?
On Sun, Nov 26, 2017 at 05:18:55PM -0500, Eric Sunshine wrote:
> On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote:
>> +int cmd_main(int argc, const char **argv)
>> +{
>> + if (argc == 2 && strcmp(argv[1], "(size_t)(-20)") == 0)
>>
On Sun, Nov 26, 2017 at 06:38:06PM +0900, Junio C Hamano wrote:
> Max Kirillov writes:
>> +static ssize_t env_content_length()
>
> We need s/length()/length(void)/; though.
thanks, fixed it
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
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
[mk: fixed trivial build failures and polished style issues]
Signed-off-by: Max Kirillov
---
config.c | 2 +-
TH is specified to a value which does not fix into ssize_t.
Signed-off-by: Max Kirillov
---
Makefile | 1 +
t/helper/test-print-values.c | 10 ++
t/t5560-http-backend-noserver.sh | 30 ++
3 files changed, 41 insertions(+)
create mode 1
On Sun, Nov 26, 2017 at 12:46:12PM +0900, Junio C Hamano wrote:
> Max Kirillov 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, &val))
> > + die
On Fri, Nov 24, 2017 at 02:54:50PM +0900, Junio C Hamano wrote:
> Max Kirillov writes:
>> I hope I marked it correctly in the trailers.
>
> It is probably more conventional to do it like so:
>
> From: Florian Manschwetus
> Date:
>
> Signed-off-by:
it is used to support chunked transfer-encoding.
Signed-off-by: Florian Manschwetus
[mk: fixed trivial build failures and polished style issues]
Signed-off-by: Max Kirillov
---
config.c | 8
config.h | 1 +
http-backend.c | 39 ++-
3 fil
TH is specified to a value which does not fix into ssize_t.
Signed-off-by: Max Kirillov
---
Makefile | 1 +
t/helper/test-print-values.c | 10 ++
t/t5560-http-backend-noserver.sh | 30 ++
3 files changed, 41 insertions(+)
create mode 1
* 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
ble is not defined, keep older behavior
of reading until EOF because it is used to support chunked transfer-encoding.
Signed-off-by: Florian Manschwetus
[mk: fixed trivial build failures and polished style issues]
Signed-off-by: Max Kirillov
---
config.c | 8
config.h |
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
TH is specified to a value which does not fix into ssize_t.
Signed-off-by: Max Kirillov
---
Makefile | 1 +
t/helper/test-print-values.c | 10 ++
t/t5560-http-backend-noserver.sh | 30 ++
3 files changed, 41 insertions(+)
create mode 1
On Sat, Nov 25, 2017 at 07:38:33PM -0500, Eric Sunshine wrote:
> On Sat, Nov 25, 2017 at 4:47 PM, Max Kirillov 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, unsigned char
>>&
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
>> **
than
the whole input until EOF. If the varibale is not defined, keep older behavior
of reading until EOF because it is used to support chunked transfer-encoding.
Signed-off-by: Florian Manschwetus
Authored-by: Florian Manschwetus
Fixed-by: Max Kirillov
Signed-off-by: Max Kirillov
---
Hi
I
On Thu, Sep 28, 2017 at 02:31:17PM +0200, Johannes Schindelin wrote:
>>> Max Kirillov writes:
>>>> Tilda-based path may confise some users. First, tilda is not known
>>>> for Window users, second, it may point to unexpected location
>>>> depending o
ot;, for example.
It should be less cryptic
Signed-off-by: Max Kirillov
---
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_check_tmp_exists {tries_left} {
add tests.
Signed-off-by: Max Kirillov
---
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 | 29 +
t/t6120
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 to
add tests.
Signed-off-by: Max Kirillov
---
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 would find
another
`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
---
builtin/describe.c | 9 ++---
t/t6120-describe.sh | 6 +-
2
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
---
gitk | 19 +--
1 file changed, 17 insertions(+), 2 d
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
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 startin
1 - 100 of 337 matches
Mail list logo
