* Re: [PATCH 6/6] refs/reftable: wire up support for exclude patterns
From: karthik nayak @ 2024-09-13 12:47 UTC (permalink / raw)
To: Patrick Steinhardt, git; +Cc: Taylor Blau
In-Reply-To: <f3922b81db69cd3bbdddcfbe02c99613448fd9ed.1725881266.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 6356 bytes --]
Patrick Steinhardt <ps@pks.im> writes:
[snip]
> hidden refs. The following benchmark prints one reference with 1 million
> hidden references:
>
> Benchmark 1: HEAD~
> Time (mean ± σ): 93.3 ms ± 2.1 ms [User: 90.3 ms, System: 2.5 ms]
> Range (min … max): 89.8 ms … 97.2 ms 33 runs
>
> Benchmark 2: HEAD
> Time (mean ± σ): 4.2 ms ± 0.6 ms [User: 2.2 ms, System: 1.8 ms]
> Range (min … max): 3.1 ms … 8.1 ms 765 runs
>
> Summary
> HEAD ran
> 22.15 ± 3.19 times faster than HEAD~
>
Nice.
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> refs/reftable-backend.c | 125 +++++++++++++++++++++++++++++++++++++++-
> t/t1419-exclude-refs.sh | 33 ++++++++---
> trace2.h | 1 +
> trace2/tr2_ctr.c | 5 ++
> 4 files changed, 152 insertions(+), 12 deletions(-)
>
> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index 1c4b19e737f..5c241097a4e 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -21,6 +21,7 @@
> #include "../reftable/reftable-iterator.h"
> #include "../setup.h"
> #include "../strmap.h"
> +#include "../trace2.h"
> #include "parse.h"
> #include "refs-internal.h"
>
> @@ -447,10 +448,81 @@ struct reftable_ref_iterator {
>
> const char *prefix;
> size_t prefix_len;
> + char **exclude_patterns;
> + size_t exclude_patterns_index;
> + size_t exclude_patterns_strlen;
> unsigned int flags;
> int err;
> };
>
> +/*
> + * Handle exclude patterns. Returns either `1`, which tells the caller that the
> + * current reference shall not be shown. Or `0`, which indicates that it should
> + * be shown.
> + */
> +static int should_exclude_current_ref(struct reftable_ref_iterator *iter)
> +{
> + while (iter->exclude_patterns[iter->exclude_patterns_index]) {
> + const char *pattern = iter->exclude_patterns[iter->exclude_patterns_index];
> + char *ref_after_pattern;
> + int cmp;
> +
> + /*
> + * Lazily cache the pattern length so that we don't have to
> + * recompute it every time this function is called.
> + */
> + if (!iter->exclude_patterns_strlen)
> + iter->exclude_patterns_strlen = strlen(pattern);
> +
> + /*
> + * When the reference name is lexicographically bigger than the
> + * current exclude pattern we know that it won't ever match any
> + * of the following references, either. We thus advance to the
> + * next pattern and re-check whether it matches.
So this means that the exclude patterns were lexicographically sorted.
Otherwise this would work.
> + * Otherwise, if it's smaller, then we do not have a match and
> + * thus want to show the current reference.
> + */
> + cmp = strncmp(iter->ref.refname, pattern,
> + iter->exclude_patterns_strlen);
> + if (cmp > 0) {
> + iter->exclude_patterns_index++;
> + iter->exclude_patterns_strlen = 0;
> + continue;
> + }
> + if (cmp < 0)
> + return 0;
> +
> + /*
> + * The reference shares a prefix with the exclude pattern and
> + * shall thus be omitted. We skip all references that match the
> + * pattern by seeking to the first reference after the block of
> + * matches.
> + *
> + * This is done by appending the highest possible character to
> + * the pattern. Consequently, all references that have the
> + * pattern as prefix and whose suffix starts with anything in
> + * the range [0x00, 0xfe] are skipped. And given that 0xff is a
> + * non-printable character that shouldn't ever be in a ref name,
> + * we'd not yield any such record, either.
> + *
This is simple yet clever.
> + * Note that the seeked-to reference may also be excluded. This
> + * is not handled here though, but the caller is expected to
> + * loop and re-verify the next reference for us.
> + */
The seeked-to reference here being the one with 0xff. We could get rid
of this by doing something like this:
int last_char_idx = iter->exclude_patterns_strlen - 1
ref_after_pattern = xstrfmt("%s", pattern);
ref_after_pattern[last_char_idx] = ref_after_pattern[last_char_idx] + 1;
instead no?
> + ref_after_pattern = xstrfmt("%s%c", pattern, 0xff);
> + iter->err = reftable_iterator_seek_ref(&iter->iter, ref_after_pattern);
> + iter->exclude_patterns_index++;
> + iter->exclude_patterns_strlen = 0;
> + trace2_counter_add(TRACE2_COUNTER_ID_REFTABLE_RESEEKS, 1);
> +
> + free(ref_after_pattern);
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> static int reftable_ref_iterator_advance(struct ref_iterator *ref_iterator)
> {
> struct reftable_ref_iterator *iter =
> @@ -481,6 +553,9 @@ static int reftable_ref_iterator_advance(struct ref_iterator *ref_iterator)
> break;
> }
>
> + if (iter->exclude_patterns && should_exclude_current_ref(iter))
> + continue;
> +
> if (iter->flags & DO_FOR_EACH_PER_WORKTREE_ONLY &&
> parse_worktree_ref(iter->ref.refname, NULL, NULL, NULL) !=
> REF_WORKTREE_CURRENT)
> @@ -570,6 +645,11 @@ static int reftable_ref_iterator_abort(struct ref_iterator *ref_iterator)
> (struct reftable_ref_iterator *)ref_iterator;
> reftable_ref_record_release(&iter->ref);
> reftable_iterator_destroy(&iter->iter);
> + if (iter->exclude_patterns) {
> + for (size_t i = 0; iter->exclude_patterns[i]; i++)
> + free(iter->exclude_patterns[i]);
> + free(iter->exclude_patterns);
> + }
> free(iter);
> return ITER_DONE;
> }
> @@ -580,9 +660,45 @@ static struct ref_iterator_vtable reftable_ref_iterator_vtable = {
> .abort = reftable_ref_iterator_abort
> };
>
> +static char **filter_exclude_patterns(const char **exclude_patterns)
> +{
> + size_t filtered_size = 0, filtered_alloc = 0;
> + char **filtered = NULL;
> +
> + if (!exclude_patterns)
> + return NULL;
> +
> + for (size_t i = 0; ; i++) {
> + const char *exclude_pattern = exclude_patterns[i];
> + int has_glob = 0;
> +
> + if (!exclude_pattern)
> + break;
> +
> + for (const char *p = exclude_pattern; *p; p++) {
> + has_glob = is_glob_special(*p);
> + if (has_glob)
> + break;
> + }
Why do we need to filter excludes here? Don't the callee's already do
something like this?
[snip]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] reftable/reader: make table iterator reseekable
From: karthik nayak @ 2024-09-13 12:11 UTC (permalink / raw)
To: Patrick Steinhardt, git; +Cc: Taylor Blau
In-Reply-To: <a281f936a2b3a697b32f57652a2120afd54f7e4f.1725881266.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]
Patrick Steinhardt <ps@pks.im> writes:
[snip]
> diff --git a/t/unit-tests/t-reftable-merged.c b/t/unit-tests/t-reftable-merged.c
> index b8c92fdb365..19e54bdfb8b 100644
> --- a/t/unit-tests/t-reftable-merged.c
> +++ b/t/unit-tests/t-reftable-merged.c
> @@ -194,6 +194,81 @@ static void t_merged_refs(void)
> reftable_free(bs);
> }
>
> +static void t_merged_seek_multiple_times(void)
> +{
> + struct reftable_ref_record r1[] = {
> + {
> + .refname = (char *) "a",
> + .update_index = 1,
> + .value_type = REFTABLE_REF_VAL1,
> + .value.val1 = { 1 },
> + },
> + {
> + .refname = (char *) "c",
> + .update_index = 1,
> + .value_type = REFTABLE_REF_VAL1,
> + .value.val1 = { 2 },
> + }
> + };
> + struct reftable_ref_record r2[] = {
> + {
> + .refname = (char *) "b",
> + .update_index = 2,
> + .value_type = REFTABLE_REF_VAL1,
> + .value.val1 = { 3 },
> + },
> + {
> + .refname = (char *) "d",
> + .update_index = 2,
> + .value_type = REFTABLE_REF_VAL1,
> + .value.val1 = { 4 },
> + },
> + };
> + struct reftable_ref_record *refs[] = {
> + r1, r2,
> + };
> + size_t sizes[] = {
> + ARRAY_SIZE(r1), ARRAY_SIZE(r2),
> + };
> + struct strbuf bufs[] = {
> + STRBUF_INIT, STRBUF_INIT,
> + };
> + struct reftable_block_source *sources = NULL;
> + struct reftable_reader **readers = NULL;
> + struct reftable_ref_record rec = { 0 };
> + struct reftable_iterator it = { 0 };
> + struct reftable_merged_table *mt;
> +
> + mt = merged_table_from_records(refs, &sources, &readers, sizes, bufs, 2);
> + merged_table_init_iter(mt, &it, BLOCK_TYPE_REF);
> +
> + for (size_t i = 0; i < 5; i++) {
> + int err = reftable_iterator_seek_ref(&it, "c");
> + check(!err);
> +
> + err = reftable_iterator_next_ref(&it, &rec);
> + check(!err);
> + err = reftable_ref_record_equal(&rec, &r1[1], GIT_SHA1_RAWSZ);
> + check(err == 1);
> +
> + err = reftable_iterator_next_ref(&it, &rec);
> + check(!err);
> + err = reftable_ref_record_equal(&rec, &r2[1], GIT_SHA1_RAWSZ);
> + check(err == 1);
> +
So this skips r2[0] because when we seek, we seek all sub-iterators. So
in r2 we seek to 'd' since that is the next alphabetical value.
[snip]
> diff --git a/t/unit-tests/t-reftable-reader.c b/t/unit-tests/t-reftable-reader.c
> new file mode 100644
> index 00000000000..7a46580b6f1
> --- /dev/null
> +++ b/t/unit-tests/t-reftable-reader.c
> @@ -0,0 +1,96 @@
> +#include "test-lib.h"
> +#include "lib-reftable.h"
> +#include "reftable/blocksource.h"
> +#include "reftable/reader.h"
> +
> +static int t_reader_seek_once(void)
> +{
> + struct reftable_ref_record records[] = {
> + {
> + .refname = (char *) "refs/heads/main",
> + .value_type = REFTABLE_REF_VAL1,
> + .value.val1 = { 42 },
> + },
> + };
> + struct reftable_block_source source = { 0 };
> + struct reftable_ref_record ref = { 0 };
> + struct reftable_iterator it = { 0 };
> + struct reftable_reader *reader;
> + struct strbuf buf = STRBUF_INIT;
> + int ret;
> +
> + t_reftable_write_to_buf(&buf, records, ARRAY_SIZE(records), NULL, 0, NULL);
> + block_source_from_strbuf(&source, &buf);
> +
> + ret = reftable_reader_new(&reader, &source, "name");
> + check_int(ret, ==, 0);
> +
> + reftable_reader_init_ref_iterator(reader, &it);
> + ret = reftable_iterator_seek_ref(&it, "");
> + check_int(ret, ==, 0);
> + ret = reftable_iterator_next_ref(&it, &ref);
> + check_int(ret, ==, 0);
> +
> + ret = reftable_ref_record_equal(&ref, &records[0], 20);
s/20/GIT_SHA1_RAWSZ
Also here and elsewhere, shouldn't we just do
`check(reftable_ref_record_equal(...))` or even
`!check(reftable_iterator_seek_ref(...))` ?
[snip]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] builtin/receive-pack: fix exclude patterns when announcing refs
From: karthik nayak @ 2024-09-13 11:50 UTC (permalink / raw)
To: Patrick Steinhardt, git; +Cc: Taylor Blau
In-Reply-To: <0317a5a7edeab29b7cad31d11140bd99f459144f.1725881266.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
Patrick Steinhardt <ps@pks.im> writes:
[snip]
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 3f35140e489..478c62ca836 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -339,12 +339,26 @@ static void show_one_alternate_ref(const struct object_id *oid,
> static void write_head_info(void)
> {
> static struct oidset seen = OIDSET_INIT;
> + struct strvec excludes_vector = STRVEC_INIT;
> + const char **exclude_patterns;
> +
> + /*
> + * We need access to the reference names both with and without their
> + * namespace and thus cannot use `refs_for_each_namespaced_ref()`. We
> + * thus have to adapt exclude patterns to carry the namespace prefix
> + * ourselves.
> + */
> + exclude_patterns = get_namespaced_exclude_patterns(
> + hidden_refs_to_excludes(&hidden_refs),
> + get_git_namespace(), &excludes_vector);
>
Nit: So we do use it here, might be worth pointing out in the previous commit.
[snip]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] refs: properly apply exclude patterns to namespaced refs
From: karthik nayak @ 2024-09-13 11:35 UTC (permalink / raw)
To: Patrick Steinhardt, git; +Cc: Taylor Blau
In-Reply-To: <8d347bc5599e2a679d50fed073e0f09ffdad85c4.1725881266.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 6571 bytes --]
Patrick Steinhardt <ps@pks.im> writes:
> Reference namespaces allow commands like git-upload-pack(1) to serve
> different sets of references to the client depending on which namespace
> is enabled, which is for example useful in fork networks. Namespaced
> refs are stored with a `refs/namespaces/$namespace` prefix, but all the
> user will ultimately see is a stripped version where that prefix is
> removed.
>
> The way that this interacts with "transfer.hideRefs" is not immediately
> obvious: the hidden refs can either apply to the stripped references, or
> to the non-stripped ones that still have the namespace prefix. In fact,
> the "transfer.hideRefs" machinery does the former and applies to the
> stripped reference by default, but rules can have "^" prefixed to switch
> this behaviour to iinstead match against the rull reference name.
s/iinstead/instead
s/rull/full
> Namespaces are exclusively handled at the generic "refs" layer, the
> respective backends have no clue that such a thing even exists. This
> also has the consequence that they cannot handle hiding references as
> soon as reference namespaces come into play because they neither know
> whether a namespace is active, nor do they know how to strip references
> if they are active.
>
> Handling such exclude patterns in `refs_for_each_namespaced_ref()` and
> `refs_for_each_fullref_in_prefixes()` is broken though, as both support
> that the user passes both namespaces and exclude patterns. In the case
> where both are set we will exclude references with unstripped names,
> even though we really wanted to exclude references based on their
> stripped names.
>
> This only surfaces when:
>
> - A repository uses reference namespaces.
>
> - "transfer.hideRefs" is active.
>
> - The namespaced references are packed into the "packed-refs" file.
>
So this is because we don't even apply exclude patterns to the loose
refs right?
To understand correctly, the transport layer passes on
'transfer.hideRefs' as `exclude_refs` to the generic refs layer. This is
mostly to optimize the reference backend to skip such refs. This is used
by the packed-refs currently but not used for loose refs.
The transfer layer also uses this list in `mark_our_ref()` to skip refs
as needed.
So all in all `exclude_refs` here is mostly for optimization.
> None of our tests exercise this scenario, and thus we haven't ever hit
> it. While t5509 exercises both (1) and (2), it does not happen to hit
> (3). It is trivial to demonstrate the bug though by explicitly packing
> refs in the tests, and then we indeed surface the breakage.
Nit: I know you're referring to the three points stated above, it would
be nice if they were numbered.
> Fix this bug by prefixing exclude patterns with the namespace in the
> generic layer.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> refs.c | 35 ++++++++++++++++++++++++++++----
> refs.h | 9 ++++++++
> t/t5509-fetch-push-namespaces.sh | 1 +
> 3 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index ceb72d4bd74..b3a367ea12c 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1517,6 +1517,19 @@ const char **hidden_refs_to_excludes(const struct strvec *hide_refs)
> return hide_refs->v;
> }
>
> +const char **get_namespaced_exclude_patterns(const char **exclude_patterns,
> + const char *namespace,
> + struct strvec *out)
> +{
> + if (!namespace || !*namespace || !exclude_patterns || !*exclude_patterns)
What scenario would `!*namespace` be possible?
> + return exclude_patterns;
> +
> + for (size_t i = 0; exclude_patterns[i]; i++)
> + strvec_pushf(out, "%s%s", namespace, exclude_patterns[i]);
> +
> + return out->v;
> +}
> +
> const char *find_descendant_ref(const char *dirname,
> const struct string_list *extras,
> const struct string_list *skip)
> @@ -1634,11 +1647,19 @@ int refs_for_each_namespaced_ref(struct ref_store *refs,
> const char **exclude_patterns,
> each_ref_fn fn, void *cb_data)
> {
> - struct strbuf buf = STRBUF_INIT;
> + struct strvec namespaced_exclude_patterns = STRVEC_INIT;
> + struct strbuf prefix = STRBUF_INIT;
> int ret;
> - strbuf_addf(&buf, "%srefs/", get_git_namespace());
> - ret = do_for_each_ref(refs, buf.buf, exclude_patterns, fn, 0, 0, cb_data);
> - strbuf_release(&buf);
> +
> + exclude_patterns = get_namespaced_exclude_patterns(exclude_patterns,
> + get_git_namespace(),
> + &namespaced_exclude_patterns);
> +
> + strbuf_addf(&prefix, "%srefs/", get_git_namespace());
> + ret = do_for_each_ref(refs, prefix.buf, exclude_patterns, fn, 0, 0, cb_data);
> +
> + strvec_clear(&namespaced_exclude_patterns);
> + strbuf_release(&prefix);
> return ret;
> }
>
> @@ -1719,6 +1740,7 @@ int refs_for_each_fullref_in_prefixes(struct ref_store *ref_store,
> const char **exclude_patterns,
> each_ref_fn fn, void *cb_data)
> {
> + struct strvec namespaced_exclude_patterns = STRVEC_INIT;
> struct string_list prefixes = STRING_LIST_INIT_DUP;
> struct string_list_item *prefix;
> struct strbuf buf = STRBUF_INIT;
> @@ -1730,6 +1752,10 @@ int refs_for_each_fullref_in_prefixes(struct ref_store *ref_store,
> strbuf_addstr(&buf, namespace);
> namespace_len = buf.len;
>
> + exclude_patterns = get_namespaced_exclude_patterns(exclude_patterns,
> + namespace,
> + &namespaced_exclude_patterns);
> +
> for_each_string_list_item(prefix, &prefixes) {
> strbuf_addstr(&buf, prefix->string);
> ret = refs_for_each_fullref_in(ref_store, buf.buf,
> @@ -1739,6 +1765,7 @@ int refs_for_each_fullref_in_prefixes(struct ref_store *ref_store,
> strbuf_setlen(&buf, namespace_len);
> }
>
> + strvec_clear(&namespaced_exclude_patterns);
> string_list_clear(&prefixes, 0);
> strbuf_release(&buf);
> return ret;
> diff --git a/refs.h b/refs.h
> index f8b919a1388..3f774e96d18 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -859,6 +859,15 @@ int ref_is_hidden(const char *, const char *, const struct strvec *);
> */
> const char **hidden_refs_to_excludes(const struct strvec *hide_refs);
>
> +/*
> + * Prefix all exclude patterns with the namespace, if any. This is required
> + * because exclude patterns apply to the stripped reference name, not the full
> + * reference name with the namespace.
> + */
> +const char **get_namespaced_exclude_patterns(const char **exclude_patterns,
> + const char *namespace,
> + struct strvec *out);
> +
Do we need to expose this? Can't it be made static?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Patrick Steinhardt @ 2024-09-13 11:21 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <o8o7sn01-p918-34s5-387p-pprqo7499p8s@unkk.fr>
On Fri, Sep 13, 2024 at 01:04:57PM +0200, Daniel Stenberg wrote:
> On Fri, 13 Sep 2024, Patrick Steinhardt wrote:
>
> > - In there we hit the `large_request` code path. We set up
> > CURLOPT_READFUNCTION and CURLOPT_SEEKFUNCTION. The callback that
> > uses our buffer is the one set up via CURLOPT_READFUNCTION, which is
> > `rpc_out()`.
>
> Thanks, I ended up able to write a stand-alone reproducer. Stefan Eissing
> wrote up a fix that seems to fix the case for us at least and it would be
> great if you could test this in your end:
>
> https://github.com/curl/curl/pull/14895
>
> The actual code patch is tiny. The PR is mostly about adding test cases to
> reproduce and verify.
I can confirm that this pull request fixes the regression. Thanks a
bunch for the quick turnaround, highly appreciated!
Patrick
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Daniel Stenberg @ 2024-09-13 11:04 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ZuP168QTTMiv_DxH@pks.im>
On Fri, 13 Sep 2024, Patrick Steinhardt wrote:
> - In there we hit the `large_request` code path. We set up
> CURLOPT_READFUNCTION and CURLOPT_SEEKFUNCTION. The callback that
> uses our buffer is the one set up via CURLOPT_READFUNCTION, which is
> `rpc_out()`.
Thanks, I ended up able to write a stand-alone reproducer. Stefan Eissing
wrote up a fix that seems to fix the case for us at least and it would be
great if you could test this in your end:
https://github.com/curl/curl/pull/14895
The actual code patch is tiny. The PR is mostly about adding test cases to
reproduce and verify.
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [PATCH v3 2/4] ref: add regular ref content check for files backend
From: shejialuo @ 2024-09-13 10:25 UTC (permalink / raw)
To: karthik nayak; +Cc: git, Patrick Steinhardt, Junio C Hamano
In-Reply-To: <CAOLa=ZT8N7TRSVNhqGrjskMTTFgO16Q4VKMVM1LPHtEorkT6cg@mail.gmail.com>
On Tue, Sep 10, 2024 at 09:07:15AM -0700, karthik nayak wrote:
[snip]
> > +static int files_fsck_refs_content(struct ref_store *ref_store,
> > + struct fsck_options *o,
> > + const char *refs_check_dir,
> > + struct dir_iterator *iter)
> > +{
> > + struct strbuf ref_content = STRBUF_INIT;
> > + struct strbuf referent = STRBUF_INIT;
> > + struct strbuf refname = STRBUF_INIT;
> > + struct fsck_ref_report report = {0};
> > + const char *trailing = NULL;
> > + unsigned int type = 0;
> > + int failure_errno = 0;
> > + struct object_id oid;
> > + int ret = 0;
> > +
> > + strbuf_addf(&refname, "%s/%s", refs_check_dir, iter->relative_path);
> > + report.path = refname.buf;
> > +
> > + if (S_ISLNK(iter->st.st_mode))
> > + goto cleanup;
>
> Since we iterate over all refs, we don't need to check the target for a
> symbolic link. So we skip all symbolic links. Makes sense. Would be nice
> to have a comment here.
>
Today I am handling the reviews, there is a misunderstanding here. It's
correct that "We don't need to check the target for a symbolic link".
But we do need to check the symbolic links. It might be a symlink
symref. In here, we just ignore the implementation and will be
implemented in the later patch.
^ permalink raw reply
* Commit signing with SSH key uses SSH_AUTH_SOCK but ignores IdentityAgent
From: Justin Su @ 2024-09-13 9:58 UTC (permalink / raw)
To: git
I use Secretive (https://github.com/maxgoedjen/secretive) to store my
SSH keys on macOS. I've configured my ssh_config to use it as the
IdentityAgent, and Git can push and pull just fine.
However, it seems that Git ignores IdentityAgent when signing commits,
resulting in the following error message:
error: No private key found for public key "foo.pub"?
fatal: failed to write commit object
I've worked around this by setting SSH_AUTH_SOCK, but this doesn't
feel correct to me. Is this intended behaviour?
Thanks,
Justin
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Patrick Steinhardt @ 2024-09-13 8:20 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <565691o1-3451-o06o-2594-2750r90nqq6p@unkk.fr>
On Fri, Sep 13, 2024 at 09:49:27AM +0200, Daniel Stenberg wrote:
> On Fri, 13 Sep 2024, Patrick Steinhardt wrote:
>
> > In a nutshell:
>
> Thanks, this is helpful.
>
> > - We then clone a repository from Apache with http.postbuffer=65536,
> > which makes us use a small buffer when POSTing data via curl. We
> > typically use 1MB buffers, and when changing it back to 1MB instead
> > of 65kB the test works just fine.
>
> Is this a git buffer size or is this a value you tell libcurl in an option
> to set a buffer size?
I'm not all that familiar with the "remote-curl.c" remote helper in Git,
so let me try to figure out things as we go.
- The code that sets up the POST buffer is `stateless_connect()`. The
buffer is allocated by ourselves.
- We then execute `post_rpc()` in a loop until we see EOF.
- `post_rpc()` itself is doing all the work to set up the curl handle,
mostly via calls to `curl_easy_setopt()`.
- In there we hit the `large_request` code path. We set up
CURLOPT_READFUNCTION and CURLOPT_SEEKFUNCTION. The callback that
uses our buffer is the one set up via CURLOPT_READFUNCTION, which is
`rpc_out()`.
Whether or not we hit `large_request` depends on out POST buffer size.
We first try to read all the data we want to send into the buffer, and
if it fits we send it out in a single call to curl by setting up
CURLOPT_POSTFIELDS and CURLOPT_POSTFIELDSIZE_LARGE. If it doesn't fit
into the buffer, which is the case for in this testcase, we instead use
the callbacks to write data via curl.
> > I've appended two curl traces, the working one with 1MB buffers and the
> > failing one with 65kB buffers. I hope that helps.
>
> How are you feeding the data to libcurl? (callback or by setting the
> postfields option?) I noticed that in the working case log, the POST
> requests always have a content-length header while the failing case log
> shows that header lacking in the final POST request.
>
> Is that on purpose?
>
> libcurl should still handle it fine, it might just be a clue for me to
> narrow down my search.
I think so. We're using a "chunked" transfer encoding in the
`large_request` case and do not yet know how much data we are about to
send. We'll only figure that out as we go.
Patrick
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Daniel Stenberg @ 2024-09-13 7:49 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ZuPdfsbHwjQPDPXc@pks.im>
On Fri, 13 Sep 2024, Patrick Steinhardt wrote:
> In a nutshell:
Thanks, this is helpful.
> - We then clone a repository from Apache with http.postbuffer=65536,
> which makes us use a small buffer when POSTing data via curl. We
> typically use 1MB buffers, and when changing it back to 1MB instead
> of 65kB the test works just fine.
Is this a git buffer size or is this a value you tell libcurl in an option to
set a buffer size?
> I've appended two curl traces, the working one with 1MB buffers and the
> failing one with 65kB buffers. I hope that helps.
How are you feeding the data to libcurl? (callback or by setting the
postfields option?) I noticed that in the working case log, the POST requests
always have a content-length header while the failing case log shows that
header lacking in the final POST request.
Is that on purpose?
libcurl should still handle it fine, it might just be a clue for me to narrow
down my search.
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [PATCH 5/4] ci: add Ubuntu 16.04 job to GitLab CI
From: Patrick Steinhardt @ 2024-09-13 6:47 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20240913064352.GA1234648@coredump.intra.peff.net>
On Fri, Sep 13, 2024 at 02:43:52AM -0400, Jeff King wrote:
> On Fri, Sep 13, 2024 at 08:39:34AM +0200, Patrick Steinhardt wrote:
>
> > > OK, this looks reasonable to me. I do think we could have our cake and
> > > eat it too on the Apache support if we added a GIT_TEST_HTTP2 knob. But
> > > it's probably not all that big a deal in practice, and after another 1.5
> > > years I think we'd drop this 16.04 job anyway (since it will be out of
> > > LTS then).
> >
> > Note that we _do_ run the Apache tests, but only for HTTP/1. That's what
> > the "auto" setting does automatically: Apache starts up just fine
> > without the HTTP/2 module and thus we run all tests that don't rely on
> > HTTP/2. On the other hand it fails to boot with HTTP/2, and thus we skip
> > over these tests automatically.
>
> Right, what I mean is that we would not notice if that job started
> skipping the HTTP/1 tests (e.g., because we changed something in
> apache.conf that didn't work on that old distro). We know it works now,
> but our ideal config going forward is "skip the HTTP/2 tests if needed,
> but fail if the HTTP/1 tests do not run".
Ah, that's true indeed. As you mention it probably doesn't matter all
that much. I think it's nice to verify that things work to the best
extent possible for such old platforms. But wiring up a new prereq just
for that doesn't feel all that important to me.
Patrick
^ permalink raw reply
* Re: [PATCH 5/4] ci: add Ubuntu 16.04 job to GitLab CI
From: Jeff King @ 2024-09-13 6:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Junio C Hamano
In-Reply-To: <ZuPeJqOg2GFqqOxa@pks.im>
On Fri, Sep 13, 2024 at 08:39:34AM +0200, Patrick Steinhardt wrote:
> > OK, this looks reasonable to me. I do think we could have our cake and
> > eat it too on the Apache support if we added a GIT_TEST_HTTP2 knob. But
> > it's probably not all that big a deal in practice, and after another 1.5
> > years I think we'd drop this 16.04 job anyway (since it will be out of
> > LTS then).
>
> Note that we _do_ run the Apache tests, but only for HTTP/1. That's what
> the "auto" setting does automatically: Apache starts up just fine
> without the HTTP/2 module and thus we run all tests that don't rely on
> HTTP/2. On the other hand it fails to boot with HTTP/2, and thus we skip
> over these tests automatically.
Right, what I mean is that we would not notice if that job started
skipping the HTTP/1 tests (e.g., because we changed something in
apache.conf that didn't work on that old distro). We know it works now,
but our ideal config going forward is "skip the HTTP/2 tests if needed,
but fail if the HTTP/1 tests do not run".
-Peff
^ permalink raw reply
* Re: [PATCH 5/4] ci: add Ubuntu 16.04 job to GitLab CI
From: Patrick Steinhardt @ 2024-09-13 6:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20240913062113.GA1232933@coredump.intra.peff.net>
On Fri, Sep 13, 2024 at 02:21:13AM -0400, Jeff King wrote:
> On Fri, Sep 13, 2024 at 07:52:51AM +0200, Patrick Steinhardt wrote:
>
> > In the preceding commits we had to convert the linux32 job to be based
> > on Ubuntu 20.04 instead of Ubuntu 16.04 due to a limitation in GitHub
> > Workflows. This was the only job left that still tested against this old
> > but supported Ubuntu version, and we have no other jobs that test with a
> > comparatively old Linux distribution.
> >
> > Add a new job to GitLab CI that tests with Ubuntu 16.04 to cover the
> > resulting test gap. GitLab doesn't modify Docker images in the same way
> > GitHub does and thus doesn't fall prey to the same issue. There are two
> > compatibility issues uncovered by this:
> >
> > - Ubuntu 16.04 does not support HTTP/2 in Apache. We thus cannot set
> > `GIT_TEST_HTTPD=true`, which would otherwise cause us to fail when
> > Apache fails to start.
> >
> > - Ubuntu 16.04 cannot use recent JGit versions as they depend on a
> > more recent Java runtime than we have available. We thus disable
> > installing any kind of optional dependencies that do not come from
> > the package manager.
>
> OK, this looks reasonable to me. I do think we could have our cake and
> eat it too on the Apache support if we added a GIT_TEST_HTTP2 knob. But
> it's probably not all that big a deal in practice, and after another 1.5
> years I think we'd drop this 16.04 job anyway (since it will be out of
> LTS then).
Note that we _do_ run the Apache tests, but only for HTTP/1. That's what
the "auto" setting does automatically: Apache starts up just fine
without the HTTP/2 module and thus we run all tests that don't rely on
HTTP/2. On the other hand it fails to boot with HTTP/2, and thus we skip
over these tests automatically.
Patrick
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Patrick Steinhardt @ 2024-09-13 6:36 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <q7soppq5-nsor-4qq9-801n-oq3461n3r889@unkk.fr>
On Fri, Sep 13, 2024 at 08:11:37AM +0200, Daniel Stenberg wrote:
> On Fri, 13 Sep 2024, Patrick Steinhardt wrote:
>
> > I noticed that GitLab's CI started to fail consistently with our
> > Alpine-based builds in t5559.30. After investigating a bit I couldn't
> > notice anything obvious on our side changing, so I checked whether
> > Alpine itself updated any packages. And indeed, it updated to curl 8.10
> > yesterday.
>
> Can you clarify for us exactly what the test case does so that we can try to
> reproduce this?
In a nutshell:
- We set up Apache with HTTP/2 support via -DHTTP2.
- We create a bunch of Git repositories to serve via Apache. The
number of refs in the repository is rather biggish.
- We then clone a repository from Apache with http.postbuffer=65536,
which makes us use a small buffer when POSTing data via curl. We
typically use 1MB buffers, and when changing it back to 1MB instead
of 65kB the test works just fine.
I've appended two curl traces, the working one with 1MB buffers and the
failing one with 65kB buffers. I hope that helps.
> We already fixed one 8.10.0 regression for HTTP/2 uploads with this PR:
>
> https://github.com/curl/curl/pull/14877
I've applid 70d3a9b6a (http2: when uploading data from stdin, fix eos
forwarding, 2024-09-12), but it doesn't fix the issue. I've also
verified that the latest `master` at 8ca603083 (RELEASE-NOTES: synced,
2024-09-12) still runs into the timeout in the same way.
Patrick
### Working, 1MB buffer
== Info: Couldn't find host 127.0.0.1 in the .netrc file; using defaults
== Info: Trying 127.0.0.1:5559...
== Info: Connected to 127.0.0.1 () port 5559
== Info: ALPN: curl offers h2,http/1.1
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
=> Send SSL data, 0000000512 bytes (0x00000200)
=> Send SSL data: ...........#v.#..qb.f.2a...d.W...+.... mNB...0K.._...\x7fUz"...
=> Send SSL data: .C.x.@5.....>.......,.0.........+./...$.(.k.#.'.g.....9.....
=> Send SSL data: 3.....=.<.5./.....u.........................................
=> Send SSL data: h2.http/1.1.........1.....*.(...............................
=> Send SSL data: ..........+............-.....3.&.$... St.........s7..[%.44g.
=> Send SSL data: .Sf7+jl..\..................................................
=> Send SSL data: ............................................................
=> Send SSL data: ............................................................
=> Send SSL data: ................................
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....z
== Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
<= Recv SSL data, 0000000122 bytes (0x0000007a)
<= Recv SSL data: ...v...o.z....a&....Bz.<,.....!.bL.f.. mNB...0K.._...\x7fUz"...
<= Recv SSL data: .C.x.@5..........+.....3.$... .".1.KV.G....X.$T......o.....x
<= Recv SSL data: 8?
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
<= Recv SSL data, 0000000015 bytes (0x0000000f)
<= Recv SSL data: .............h2
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Certificate (11):
<= Recv SSL data, 0000000704 bytes (0x000002c0)
<= Recv SSL data: ...........0...0........,./..H.cz....e..40...*.H........0.1.
<= Recv SSL data: 0...U....127.0.0.10...240913063249Z..241013063249Z0.1.0...U.
<= Recv SSL data: ...127.0.0.10.."0...*.H.............0..........F....OHgR..(.
<= Recv SSL data: ......X\.ue.r.|.?....k}..9.0.J....=0..".Y+w&.m.=.a._!..Z....
<= Recv SSL data: .]U.M.\.Dk....a. v.j.pV8..FU..;..j.e.M...'<............y...t
<= Recv SSL data: ....W&....e.......d......7.7}..j.!..._8.n..5..+..........x..
<= Recv SSL data: .v.........ef.....bpe..../....^.Tu....;NG.R..Y...K...L....l.
<= Recv SSL data: y.....0...*.H..............1w...w......c..i.P..2....Ht.:u0..
<= Recv SSL data: Ef!d}....\x7f*KNv\x7f."b....|..d..>s..M6......u..;.....&J<...<@.qg
<= Recv SSL data: ....GD.....3.6... ....Q..Nk..f.xf.xP>....]..m=.[OP0..,..t..3
<= Recv SSL data: ..iE8B..Mu....4j.=. ...ll.1....k.2<.]w.U..*.&..k.C....T.6.A.
<= Recv SSL data: ......t..O...rW...1..A..y.b...I.........]...
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, CERT verify (15):
<= Recv SSL data, 0000000264 bytes (0x00000108)
<= Recv SSL data: ........Y.s.'.=qB.Mh.j!\..j.........>.1..F...n85n(/.........
<= Recv SSL data: ....[!5Jq.\.7....E...#...,-:...m......}..4..#N.n.\+v].ae...7
<= Recv SSL data: zy..r..f.8..e...".........L..<....Hf.k;.[ M..xhY2.."L..aS4..
<= Recv SSL data: .(..:..7.....`...%. .i.uh...... oVA...iIe.Sg/.qrkN...V9.n..P
<= Recv SSL data: .......f_..G"....:.E.%@P
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....E
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Finished (20):
<= Recv SSL data, 0000000052 bytes (0x00000034)
<= Recv SSL data: ...0D~...K.{.t_KQ.v.S...v...M...;......j..B.:tWf...x
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
== Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....E
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
== Info: TLSv1.3 (OUT), TLS handshake, Finished (20):
=> Send SSL data, 0000000052 bytes (0x00000034)
=> Send SSL data: ...0.b..0..k.[.N..z.G.....*.......tMqU..Q."(E8.L...3
== Info: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
== Info: ALPN: server accepted h2
== Info: Server certificate:
== Info: subject: CN=127.0.0.1
== Info: start date: Sep 13 06:32:49 2024 GMT
== Info: expire date: Oct 13 06:32:49 2024 GMT
== Info: issuer: CN=127.0.0.1
== Info: SSL certificate verify result: self-signed certificate (18), continuing anyway.
== Info: Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....Q
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
== Info: using HTTP/2
== Info: [HTTP/2] [1] OPENED stream for https://127.0.0.1:5559/smart/repo.git/info/refs?service=git-upload-pack
== Info: [HTTP/2] [1] [:method: GET]
== Info: [HTTP/2] [1] [:scheme: https]
== Info: [HTTP/2] [1] [:authority: 127.0.0.1:5559]
== Info: [HTTP/2] [1] [:path: /smart/repo.git/info/refs?service=git-upload-pack]
== Info: [HTTP/2] [1] [user-agent: git/2.46.0.556.gcfcff505c7f.dirty]
== Info: [HTTP/2] [1] [accept: */*]
== Info: [HTTP/2] [1] [accept-encoding: deflate, gzip, br, zstd]
== Info: [HTTP/2] [1] [pragma: no-cache]
== Info: [HTTP/2] [1] [git-protocol: version=2]
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send header, 0000000231 bytes (0x000000e7)
=> Send header: GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/2
=> Send header: Host: 127.0.0.1:5559
=> Send header: User-Agent: git/2.46.0.556.gcfcff505c7f.dirty
=> Send header: Accept: */*
=> Send header: Accept-Encoding: deflate, gzip, br, zstd
=> Send header: Pragma: no-cache
=> Send header: Git-Protocol: version=2
=> Send header:
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
<= Recv SSL data, 0000000265 bytes (0x00000109)
<= Recv SSL data: .......,9.J............#....GL.A-J.E..%...+.Q..O,.I..0F.....
<= Recv SSL data: ...~{O.50W(._..}..k.6..sU\x7fo..OZS.&.c.m.1a..|.1xQH...KWf.....
<= Recv SSL data: ....P.i(V.@...@......8.%x7M.....Z.T..t..Q..'..#..h.[..'jp...
<= Recv SSL data: ......p}[.mB....HD..F%[d...]$P.S....C.J%Q=.&.R...M5E._..7.?.
<= Recv SSL data: .^. Q.I..-..b,.....K..,..
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
<= Recv SSL data, 0000000265 bytes (0x00000109)
<= Recv SSL data: .......,..V............#....GL.A-J.E..%$.....D.A..5.......B.
<= Recv SSL data: 5..'.Y..X,.Z...ba..[.)0...eZ-.X......iZ)...0.......w.d...km.
<= Recv SSL data: ..I.m...`W..r.?...B.. 7.yF....RLW.Mt"4.q....(.$>bE.....OT..D
<= Recv SSL data: u.x...o.O*..T:t...N..3.o.c... ........A...*e.:.tD...F.....=.
<= Recv SSL data: ..*..8....P...._...|..0..
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....-
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
== Info: Request completely sent off
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv header, 0000000013 bytes (0x0000000d)
<= Recv header: HTTP/2 200
<= Recv header, 0000000040 bytes (0x00000028)
<= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
<= Recv header, 0000000018 bytes (0x00000012)
<= Recv header: pragma: no-cache
<= Recv header, 0000000053 bytes (0x00000035)
<= Recv header: cache-control: no-cache, max-age=0, must-revalidate
<= Recv header, 0000000059 bytes (0x0000003b)
<= Recv header: content-type: application/x-git-upload-pack-advertisement
<= Recv header, 0000000037 bytes (0x00000025)
<= Recv header: date: Fri, 13 Sep 2024 06:32:49 GMT
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: server: Apache/2.4.62 (Unix) OpenSSL/3.0.14
<= Recv header, 0000000002 bytes (0x00000002)
<= Recv header:
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000154 bytes (0x0000009a)
<= Recv data: 000eversion 2.002cagent=git/2.46.0.556.gcfcff505c7f.dirty.00
<= Recv data: 13ls-refs=unborn.0020fetch=shallow wait-for-done.0012server-
<= Recv data: option.0017object-format=sha1.0000
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000000 bytes (0x00000000)
== Info: Connection #0 to host 127.0.0.1 left intact
== Info: Couldn't find host 127.0.0.1 in the .netrc file; using defaults
== Info: Re-using existing connection with host 127.0.0.1
== Info: [HTTP/2] [3] OPENED stream for https://127.0.0.1:5559/smart/repo.git/git-upload-pack
== Info: [HTTP/2] [3] [:method: POST]
== Info: [HTTP/2] [3] [:scheme: https]
== Info: [HTTP/2] [3] [:authority: 127.0.0.1:5559]
== Info: [HTTP/2] [3] [:path: /smart/repo.git/git-upload-pack]
== Info: [HTTP/2] [3] [user-agent: git/2.46.0.556.gcfcff505c7f.dirty]
== Info: [HTTP/2] [3] [accept-encoding: deflate, gzip, br, zstd]
== Info: [HTTP/2] [3] [content-type: application/x-git-upload-pack-request]
== Info: [HTTP/2] [3] [accept: application/x-git-upload-pack-result]
== Info: [HTTP/2] [3] [git-protocol: version=2]
== Info: [HTTP/2] [3] [content-length: 198]
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....E
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send header, 0000000303 bytes (0x0000012f)
=> Send header: POST /smart/repo.git/git-upload-pack HTTP/2
=> Send header: Host: 127.0.0.1:5559
=> Send header: User-Agent: git/2.46.0.556.gcfcff505c7f.dirty
=> Send header: Accept-Encoding: deflate, gzip, br, zstd
=> Send header: Content-Type: application/x-git-upload-pack-request
=> Send header: Accept: application/x-git-upload-pack-result
=> Send header: Git-Protocol: version=2
=> Send header: Content-Length: 198
=> Send header:
=> Send data, 0000000198 bytes (0x000000c6)
=> Send data: 0014command=ls-refs.002bagent=git/2.46.0.556.gcfcff505c7f.di
=> Send data: rty0016object-format=sha100010009peel.000csymrefs.000bunborn
=> Send data: .0014ref-prefix HEAD.001bref-prefix refs/heads/.001aref-pref
=> Send data: ix refs/tags/.0000
== Info: upload completely sent off: 198 bytes
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....<
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv header, 0000000013 bytes (0x0000000d)
<= Recv header: HTTP/2 200
<= Recv header, 0000000040 bytes (0x00000028)
<= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
<= Recv header, 0000000018 bytes (0x00000012)
<= Recv header: pragma: no-cache
<= Recv header, 0000000053 bytes (0x00000035)
<= Recv header: cache-control: no-cache, max-age=0, must-revalidate
<= Recv header, 0000000052 bytes (0x00000034)
<= Recv header: content-type: application/x-git-upload-pack-result
<= Recv header, 0000000037 bytes (0x00000025)
<= Recv header: date: Fri, 13 Sep 2024 06:32:49 GMT
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: server: Apache/2.4.62 (Unix) OpenSSL/3.0.14
<= Recv header, 0000000002 bytes (0x00000002)
<= Recv header:
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000145 bytes (0x00000091)
<= Recv data: 0050f39a92305d069e3dcdc4ce95c3001deec3642dc3 HEAD symref-tar
<= Recv data: get:refs/heads/main.003df39a92305d069e3dcdc4ce95c3001deec364
<= Recv data: 2dc3 refs/heads/main.0000
<= Recv data, 0000000000 bytes (0x00000000)
== Info: Connection #0 to host 127.0.0.1 left intact
== Info: Couldn't find host 127.0.0.1 in the .netrc file; using defaults
== Info: Re-using existing connection with host 127.0.0.1
== Info: [HTTP/2] [5] OPENED stream for https://127.0.0.1:5559/smart/repo.git/git-upload-pack
== Info: [HTTP/2] [5] [:method: POST]
== Info: [HTTP/2] [5] [:scheme: https]
== Info: [HTTP/2] [5] [:authority: 127.0.0.1:5559]
== Info: [HTTP/2] [5] [:path: /smart/repo.git/git-upload-pack]
== Info: [HTTP/2] [5] [user-agent: git/2.46.0.556.gcfcff505c7f.dirty]
== Info: [HTTP/2] [5] [accept-encoding: deflate, gzip, br, zstd]
== Info: [HTTP/2] [5] [content-type: application/x-git-upload-pack-request]
== Info: [HTTP/2] [5] [accept: application/x-git-upload-pack-result]
== Info: [HTTP/2] [5] [git-protocol: version=2]
== Info: [HTTP/2] [5] [content-length: 240]
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....8
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send header, 0000000303 bytes (0x0000012f)
=> Send header: POST /smart/repo.git/git-upload-pack HTTP/2
=> Send header: Host: 127.0.0.1:5559
=> Send header: User-Agent: git/2.46.0.556.gcfcff505c7f.dirty
=> Send header: Accept-Encoding: deflate, gzip, br, zstd
=> Send header: Content-Type: application/x-git-upload-pack-request
=> Send header: Accept: application/x-git-upload-pack-result
=> Send header: Git-Protocol: version=2
=> Send header: Content-Length: 240
=> Send header:
=> Send data, 0000000240 bytes (0x000000f0)
=> Send data: 0011command=fetch002bagent=git/2.46.0.556.gcfcff505c7f.dirty
=> Send data: 0016object-format=sha10001000dthin-pack000fno-progress000dof
=> Send data: s-delta0032want f39a92305d069e3dcdc4ce95c3001deec3642dc3.003
=> Send data: 2want f39a92305d069e3dcdc4ce95c3001deec3642dc3.0009done.0000
== Info: upload completely sent off: 240 bytes
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....!
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv header, 0000000013 bytes (0x0000000d)
<= Recv header: HTTP/2 200
<= Recv header, 0000000040 bytes (0x00000028)
<= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
<= Recv header, 0000000018 bytes (0x00000012)
<= Recv header: pragma: no-cache
<= Recv header, 0000000053 bytes (0x00000035)
<= Recv header: cache-control: no-cache, max-age=0, must-revalidate
<= Recv header, 0000000052 bytes (0x00000034)
<= Recv header: content-type: application/x-git-upload-pack-result
<= Recv header, 0000000037 bytes (0x00000025)
<= Recv header: date: Fri, 13 Sep 2024 06:32:49 GMT
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: server: Apache/2.4.62 (Unix) OpenSSL/3.0.14
<= Recv header, 0000000002 bytes (0x00000002)
<= Recv header:
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....'
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000013 bytes (0x0000000d)
<= Recv data: 000dpackfile.
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000230 bytes (0x000000e6)
<= Recv data: 00e0.PACK..........x.+)JMU00775N31.073ML6LLK5202H22I510.0.0.
<= Recv data: LJ1I.0.J,-../RpT.U..1l .......9.z...v....F..&.....@c......%%
<= Recv data: .E.........\..n...T....0...x.340031QH..Ie..ou..].Ui...`.....
<= Recv data: O.......8x.K..+I.+........}....#Z.l.R.v.D.\.0006..
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000004 bytes (0x00000004)
<= Recv data: 0000
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000000 bytes (0x00000000)
== Info: Connection #0 to host 127.0.0.1 left intact
### Failing
== Info: Couldn't find host 127.0.0.1 in the .netrc file; using defaults
== Info: Trying 127.0.0.1:5559...
== Info: Connected to 127.0.0.1 () port 5559
== Info: ALPN: curl offers h2,http/1.1
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
=> Send SSL data, 0000000512 bytes (0x00000200)
=> Send SSL data: .......e.K.6.u....b..."p.p..0.S...oJ}. .6...........a....!..
=> Send SSL data: ...Q..u.9...>.......,.0.........+./...$.(.k.#.'.g.....9.....
=> Send SSL data: 3.....=.<.5./.....u.........................................
=> Send SSL data: h2.http/1.1.........1.....*.(...............................
=> Send SSL data: ..........+............-.....3.&.$... ....S..[%t.S].+......4
=> Send SSL data: .C.G\x7f..<.;..................................................
=> Send SSL data: ............................................................
=> Send SSL data: ............................................................
=> Send SSL data: ................................
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....z
== Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
<= Recv SSL data, 0000000122 bytes (0x0000007a)
<= Recv SSL data: ...v......%.jD]3....Q...t.v.;....H.K;. .6...........a....!..
<= Recv SSL data: ...Q..u.9........+.....3.$... ...(......r.^.=L......FmI.CS.A
<= Recv SSL data: .4
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
<= Recv SSL data, 0000000015 bytes (0x0000000f)
<= Recv SSL data: .............h2
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Certificate (11):
<= Recv SSL data, 0000000704 bytes (0x000002c0)
<= Recv SSL data: ...........0...0.....O~.......F.......I.d0...*.H........0.1.
<= Recv SSL data: 0...U....127.0.0.10...240913063318Z..241013063318Z0.1.0...U.
<= Recv SSL data: ...127.0.0.10.."0...*.H.............0.........y..i.^xtl.....
<= Recv SSL data: .D:..g...B[................s.P.Ea.O...M[....#Q. ..g._U.&..l9
<= Recv SSL data: ...uU......w... ...6.x...U........&.H|.+....H..bm....w...tx.
<= Recv SSL data: .....~\k....f4........u...6..1.[Z.Bu.X...H...!..h%.O.'.RdNG.
<= Recv SSL data: o..V.p.0.u60.....<.....^kC..n.w..=..y.*J(n....m...lB...K....
<= Recv SSL data: ......0...*.H..............[....0.X..if.C{....d..n....k.AI..
<= Recv SSL data: ......Q..m....>.m.i^.W\x7f.S..,Pt.m.........Uo..Qk.*.u.w..9lM..
<= Recv SSL data: .........k....L2.5..7+...j.cU...E.je..QPG.jt..H..~.P.(.../.A
<= Recv SSL data: ..S.b...[hV.r....35.`..(..a.........u<e.9..P.N........8..*.%
<= Recv SSL data: \(.......Sj...\l.3J...\x7f..#..={.~...^...Zv...
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, CERT verify (15):
<= Recv SSL data, 0000000264 bytes (0x00000108)
<= Recv SSL data: ........o.P..jt.2m.L4)..9p...K..................i.. G.$yz.U
<= Recv SSL data: A..s.CPk.....A........]....f.P.\(0...>..a.~}"......|.5....=.
<= Recv SSL data: N...|.6.M.g....1.........>.8.....h1....-.1.].o.yO......Ex(.g
<= Recv SSL data: .Y.u..+...<.2...[::y.....2bL.....|..._.<...n.9.+d....X.8-A~D
<= Recv SSL data: _.T.^.}......c..A]*G....
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....E
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Finished (20):
<= Recv SSL data, 0000000052 bytes (0x00000034)
<= Recv SSL data: ...0...nl.I..$..f.3.3T.+.i.......8f..1e.{G.....@5J..
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
== Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....E
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
== Info: TLSv1.3 (OUT), TLS handshake, Finished (20):
=> Send SSL data, 0000000052 bytes (0x00000034)
=> Send SSL data: ...0|.*2\{U.Z.<..9.......-i..9..bnE. V....R...([.d..
== Info: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
== Info: ALPN: server accepted h2
== Info: Server certificate:
== Info: subject: CN=127.0.0.1
== Info: start date: Sep 13 06:33:18 2024 GMT
== Info: expire date: Oct 13 06:33:18 2024 GMT
== Info: issuer: CN=127.0.0.1
== Info: SSL certificate verify result: self-signed certificate (18), continuing anyway.
== Info: Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....Q
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
== Info: using HTTP/2
== Info: [HTTP/2] [1] OPENED stream for https://127.0.0.1:5559/smart/repo.git/info/refs?service=git-upload-pack
== Info: [HTTP/2] [1] [:method: GET]
== Info: [HTTP/2] [1] [:scheme: https]
== Info: [HTTP/2] [1] [:authority: 127.0.0.1:5559]
== Info: [HTTP/2] [1] [:path: /smart/repo.git/info/refs?service=git-upload-pack]
== Info: [HTTP/2] [1] [user-agent: git/2.46.0.556.gcfcff505c7f.dirty]
== Info: [HTTP/2] [1] [accept: */*]
== Info: [HTTP/2] [1] [accept-encoding: deflate, gzip, br, zstd]
== Info: [HTTP/2] [1] [pragma: no-cache]
== Info: [HTTP/2] [1] [git-protocol: version=2]
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send header, 0000000231 bytes (0x000000e7)
=> Send header: GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/2
=> Send header: Host: 127.0.0.1:5559
=> Send header: User-Agent: git/2.46.0.556.gcfcff505c7f.dirty
=> Send header: Accept: */*
=> Send header: Accept-Encoding: deflate, gzip, br, zstd
=> Send header: Pragma: no-cache
=> Send header: Git-Protocol: version=2
=> Send header:
== Info: Request completely sent off
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
<= Recv SSL data, 0000000265 bytes (0x00000109)
<= Recv SSL data: .......,.#..............<....T..Xpu..............X~.......b.
<= Recv SSL data: ..dW{-.*@...!c.....C..."4<...o.8\.W^Yhev.w.o......k.e...A.B.
<= Recv SSL data: ....k..B....R..R....3...G.X<.nO>...v|.7z'..(+...u<.Ob../.*y.
<= Recv SSL data: :a.=..`..1..F c..G..H....'8....|h.\x7f.?.b................./f#.
<= Recv SSL data: ..n.......\x7f..x..M...)t...
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
== Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
<= Recv SSL data, 0000000265 bytes (0x00000109)
<= Recv SSL data: .......,{.p.............<....T..Xpu.....v........".,.a<...lV
<= Recv SSL data: .v..g.........k.....zjo........J..... .. _....u....S..v...>.
<= Recv SSL data: ...}.N.9#bc.(.-kn..G5..N.....4....i^6.&....}..../b.z.`......
<= Recv SSL data: .-....I.C.w../..[.._W.Id..Q,..n....F(`.....t...K.\.......2.O
<= Recv SSL data: ..u.-..x..A..e....D.[8@..
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....-
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv header, 0000000013 bytes (0x0000000d)
<= Recv header: HTTP/2 200
<= Recv header, 0000000040 bytes (0x00000028)
<= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
<= Recv header, 0000000018 bytes (0x00000012)
<= Recv header: pragma: no-cache
<= Recv header, 0000000053 bytes (0x00000035)
<= Recv header: cache-control: no-cache, max-age=0, must-revalidate
<= Recv header, 0000000059 bytes (0x0000003b)
<= Recv header: content-type: application/x-git-upload-pack-advertisement
<= Recv header, 0000000037 bytes (0x00000025)
<= Recv header: date: Fri, 13 Sep 2024 06:33:18 GMT
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: server: Apache/2.4.62 (Unix) OpenSSL/3.0.14
<= Recv header, 0000000002 bytes (0x00000002)
<= Recv header:
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000154 bytes (0x0000009a)
<= Recv data: 000eversion 2.002cagent=git/2.46.0.556.gcfcff505c7f.dirty.00
<= Recv data: 13ls-refs=unborn.0020fetch=shallow wait-for-done.0012server-
<= Recv data: option.0017object-format=sha1.0000
<= Recv data, 0000000000 bytes (0x00000000)
== Info: Connection #0 to host 127.0.0.1 left intact
== Info: Couldn't find host 127.0.0.1 in the .netrc file; using defaults
== Info: Re-using existing connection with host 127.0.0.1
== Info: [HTTP/2] [3] OPENED stream for https://127.0.0.1:5559/smart/repo.git/git-upload-pack
== Info: [HTTP/2] [3] [:method: POST]
== Info: [HTTP/2] [3] [:scheme: https]
== Info: [HTTP/2] [3] [:authority: 127.0.0.1:5559]
== Info: [HTTP/2] [3] [:path: /smart/repo.git/git-upload-pack]
== Info: [HTTP/2] [3] [user-agent: git/2.46.0.556.gcfcff505c7f.dirty]
== Info: [HTTP/2] [3] [content-type: application/x-git-upload-pack-request]
== Info: [HTTP/2] [3] [accept: application/x-git-upload-pack-result]
== Info: [HTTP/2] [3] [content-length: 4]
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....\x7f
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send header, 0000000234 bytes (0x000000ea)
=> Send header: POST /smart/repo.git/git-upload-pack HTTP/2
=> Send header: Host: 127.0.0.1:5559
=> Send header: User-Agent: git/2.46.0.556.gcfcff505c7f.dirty
=> Send header: Content-Type: application/x-git-upload-pack-request
=> Send header: Accept: application/x-git-upload-pack-result
=> Send header: Content-Length: 4
=> Send header:
=> Send data, 0000000004 bytes (0x00000004)
=> Send data: 0000
== Info: upload completely sent off: 4 bytes
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....<
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv header, 0000000013 bytes (0x0000000d)
<= Recv header: HTTP/2 200
<= Recv header, 0000000040 bytes (0x00000028)
<= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
<= Recv header, 0000000018 bytes (0x00000012)
<= Recv header: pragma: no-cache
<= Recv header, 0000000053 bytes (0x00000035)
<= Recv header: cache-control: no-cache, max-age=0, must-revalidate
<= Recv header, 0000000052 bytes (0x00000034)
<= Recv header: content-type: application/x-git-upload-pack-result
<= Recv header, 0000000037 bytes (0x00000025)
<= Recv header: date: Fri, 13 Sep 2024 06:33:18 GMT
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: server: Apache/2.4.62 (Unix) OpenSSL/3.0.14
<= Recv header, 0000000002 bytes (0x00000002)
<= Recv header:
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: .....
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv data, 0000000000 bytes (0x00000000)
== Info: Connection #0 to host 127.0.0.1 left intact
== Info: Couldn't find host 127.0.0.1 in the .netrc file; using defaults
== Info: Re-using existing connection with host 127.0.0.1
== Info: [HTTP/2] [5] OPENED stream for https://127.0.0.1:5559/smart/repo.git/git-upload-pack
== Info: [HTTP/2] [5] [:method: POST]
== Info: [HTTP/2] [5] [:scheme: https]
== Info: [HTTP/2] [5] [:authority: 127.0.0.1:5559]
== Info: [HTTP/2] [5] [:path: /smart/repo.git/git-upload-pack]
== Info: [HTTP/2] [5] [user-agent: git/2.46.0.556.gcfcff505c7f.dirty]
== Info: [HTTP/2] [5] [accept-encoding: deflate, gzip, br, zstd]
== Info: [HTTP/2] [5] [content-type: application/x-git-upload-pack-request]
== Info: [HTTP/2] [5] [accept: application/x-git-upload-pack-result]
== Info: [HTTP/2] [5] [git-protocol: version=2]
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....W
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send header, 0000000282 bytes (0x0000011a)
=> Send header: POST /smart/repo.git/git-upload-pack HTTP/2
=> Send header: Host: 127.0.0.1:5559
=> Send header: User-Agent: git/2.46.0.556.gcfcff505c7f.dirty
=> Send header: Accept-Encoding: deflate, gzip, br, zstd
=> Send header: Content-Type: application/x-git-upload-pack-request
=> Send header: Accept: application/x-git-upload-pack-result
=> Send header: Git-Protocol: version=2
=> Send header:
=> Send data, 0000000020 bytes (0x00000014)
=> Send data: 0014command=ls-refs.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....E
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000043 bytes (0x0000002b)
=> Send data: 002bagent=git/2.46.0.556.gcfcff505c7f.dirty
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....0
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000022 bytes (0x00000016)
=> Send data: 0016object-format=sha1
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000004 bytes (0x00000004)
=> Send data: 0001
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....#
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000009 bytes (0x00000009)
=> Send data: 0009peel.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....&
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000012 bytes (0x0000000c)
=> Send data: 000csymrefs.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....%
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000011 bytes (0x0000000b)
=> Send data: 000bunborn.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000020 bytes (0x00000014)
=> Send data: 0014ref-prefix HEAD.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....5
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000027 bytes (0x0000001b)
=> Send data: 001bref-prefix refs/heads/.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: ....4
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000026 bytes (0x0000001a)
=> Send data: 001aref-prefix refs/tags/.
=> Send SSL data, 0000000005 bytes (0x00000005)
=> Send SSL data: .....
=> Send SSL data, 0000000001 bytes (0x00000001)
=> Send SSL data: .
=> Send data, 0000000004 bytes (0x00000004)
=> Send data: 0000
== Info: upload completely sent off: 198 bytes
<= Recv SSL data, 0000000005 bytes (0x00000005)
<= Recv SSL data: ....0
<= Recv SSL data, 0000000001 bytes (0x00000001)
<= Recv SSL data: .
<= Recv header, 0000000013 bytes (0x0000000d)
<= Recv header: HTTP/2 408
<= Recv header, 0000000021 bytes (0x00000015)
<= Recv header: content-length: 221
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: content-type: text/html; charset=iso-8859-1
<= Recv header, 0000000037 bytes (0x00000025)
<= Recv header: date: Fri, 13 Sep 2024 06:33:18 GMT
<= Recv header, 0000000045 bytes (0x0000002d)
<= Recv header: server: Apache/2.4.62 (Unix) OpenSSL/3.0.14
<= Recv header, 0000000002 bytes (0x00000002)
<= Recv header:
<= Recv data, 0000000221 bytes (0x000000dd)
<= Recv data: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">.<html><he
<= Recv data: ad>.<title>408 Request Timeout</title>.</head><body>.<h1>Req
<= Recv data: uest Timeout</h1>.<p>Server timeout waiting for the HTTP req
<= Recv data: uest from the client.</p>.</body></html>.
<= Recv data, 0000000000 bytes (0x00000000)
== Info: Connection #0 to host 127.0.0.1 left intact
^ permalink raw reply
* Re: [PATCH 5/4] ci: add Ubuntu 16.04 job to GitLab CI
From: Jeff King @ 2024-09-13 6:21 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Junio C Hamano
In-Reply-To: <00a9fe6b7d77c16c9fd6dfe746aacf9068a76942.1726206484.git.ps@pks.im>
On Fri, Sep 13, 2024 at 07:52:51AM +0200, Patrick Steinhardt wrote:
> In the preceding commits we had to convert the linux32 job to be based
> on Ubuntu 20.04 instead of Ubuntu 16.04 due to a limitation in GitHub
> Workflows. This was the only job left that still tested against this old
> but supported Ubuntu version, and we have no other jobs that test with a
> comparatively old Linux distribution.
>
> Add a new job to GitLab CI that tests with Ubuntu 16.04 to cover the
> resulting test gap. GitLab doesn't modify Docker images in the same way
> GitHub does and thus doesn't fall prey to the same issue. There are two
> compatibility issues uncovered by this:
>
> - Ubuntu 16.04 does not support HTTP/2 in Apache. We thus cannot set
> `GIT_TEST_HTTPD=true`, which would otherwise cause us to fail when
> Apache fails to start.
>
> - Ubuntu 16.04 cannot use recent JGit versions as they depend on a
> more recent Java runtime than we have available. We thus disable
> installing any kind of optional dependencies that do not come from
> the package manager.
OK, this looks reasonable to me. I do think we could have our cake and
eat it too on the Apache support if we added a GIT_TEST_HTTP2 knob. But
it's probably not all that big a deal in practice, and after another 1.5
years I think we'd drop this 16.04 job anyway (since it will be out of
LTS then).
Thanks for putting this together.
-Peff
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Daniel Stenberg @ 2024-09-13 6:11 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ZuPKvYP9ZZ2mhb4m@pks.im>
On Fri, 13 Sep 2024, Patrick Steinhardt wrote:
> I noticed that GitLab's CI started to fail consistently with our
> Alpine-based builds in t5559.30. After investigating a bit I couldn't notice
> anything obvious on our side changing, so I checked whether Alpine itself
> updated any packages. And indeed, it updated to curl 8.10 yesterday.
Can you clarify for us exactly what the test case does so that we can try to
reproduce this?
We already fixed one 8.10.0 regression for HTTP/2 uploads with this PR:
https://github.com/curl/curl/pull/14877
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [PATCH] remote: introduce config to set prefetch refs
From: Shubham Kanodia @ 2024-09-13 6:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shubham Kanodia via GitGitGadget, git, Patrick Steinhardt [ ],
Derrick Stolee [ ]
In-Reply-To: <xmqq5xr4r818.fsf@gitster.g>
On Tue, Sep 10, 2024 at 12:03 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Shubham Kanodia <shubham.kanodia10@gmail.com> writes:
>
> > How should we handle the related `remote.<remote-name>.fetch` config?
>
> The get_ref_map() helper is what the rest of the code interacts with
> configured refspec. remote->fetch is handled there and goes through
> the same filter_prefetch_refspec().
>
> > In an earlier discussion, it was discussed that —
> > `.prefetchref` should override `.fetch` completely (instead of
> > patching it) which makes sense to me.
>
> Maybe it made sense to you back when it was discussed, but after
> seeing the current code (before applying this patch), specifically
> what happens in filter_prefetch_refspec(), it no longer makes much
> sense to me.
>
> Especially it is nonsense to allow .prefetchref to widen the set of
> refs that are being prefetched beyond what is normally fetched, so
> we should look at a design that easily allows such a configuration
> with strong suspicion, I would think.
Ideally, a repository should be able to specify (say):
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.prefetchref=refs/heads/main
This configuration would maintain the normal behavior for fetches, but
only prefetch the main branch.
The rationale for this is that the main branch typically serves as the
HEAD from which future branches will be forked in an active
repository.
Regarding:
> If prefetch_refs contains only positive patterns, then a refspec whose source
> doesn't match any of these patterns is rejected.
Simply rejecting a source refspec pattern in `remote.<remote>.fetch`
wouldn't achieve our goal here.
Ideally, we'd need to create a subset of it.
What we're looking for is essentially a pattern intersection between
the (fetch) `refs/heads/*` and the (prefetchref) `refs/heads/main`,
which in this case would result in `refs/heads/main`.
However, if I understand correctly, performing such pattern
intersections isn't straightforward in the `filter_prefetch_refspec`
function (let me know if there' prior art for pattern intersection)
I also believe that allowing negative refs might complicate things
without providing a clear use case.
For instance, how would we handle the intersection of `fetch` and
`prefetchref` if `prefetchref` contained both positive and negative
patterns?
Given that both `fetch` and `prefetchref` could have multiple
patterns, it might be simpler and more intuitive for users if we adopt
an "A wins over B" approach.
However, I'm interested in hearing your thoughts on this matter.
Perhaps I should link to the earlier discussion here —
Message ID (CAG=Um+1wTbXn_RN+LOCrpZpSNR_QF582PszxNyhz5anVHtBp+w@mail.gmail.com)
^ permalink raw reply
* Re: curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Daniel Stenberg @ 2024-09-13 6:15 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <q7soppq5-nsor-4qq9-801n-oq3461n3r889@unkk.fr>
On Fri, 13 Sep 2024, Daniel Stenberg wrote:
> We already fixed one 8.10.0 regression for HTTP/2 uploads with this PR:
I should also probably mention that we plan to ship curl 8.10.1 on September
18, addressing this and a few other regressions.
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [PATCH 0/2] Simplify "commented" API functions
From: Patrick Steinhardt @ 2024-09-13 6:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20240912205301.1809355-1-gitster@pobox.com>
On Thu, Sep 12, 2024 at 01:52:59PM -0700, Junio C Hamano wrote:
> We [earlier] noticed that a few helper functions that format strings
> into a strbuf, prefixed with an arbitrary comment leading character,
> are forcing their callers to always pass the same argument. Instead
> of keeping this excess flexibility nobody wants in practice, narrow
> the API so that all callers of these functions will get the same
> comment leading character.
>
> Superficially it may appear that this goes against one of the recent
> trend, "war on global variables", but I doubt it matters much in the
> longer run.
I'm not quite sure I agree. The comment strings we have are in theory
broken, because they can be configured differently per repository. So if
you happen to have a Git command that operates on multiple repositories
at once and that needs to pay attention to that config then it would now
use the same comment character for both repositories, which I'd argue is
the wrong thing to do.
The recent patch series that makes "environment.c" aware of
`USE_THE_REPOSITORY_VARIABLE` already converted some of the global
config variables to be per-repository, because ultimately all of them
are broken in the described way. So from my point of view we should aim
to convert remaining ones to be per-repository, as well.
> These call sites all have already been relying on the global
> "comment_line_str" anyway, and passing the variable from the top of
> arbitrary deep call chain, which may not care specifically about
> this single variable comment_line_str, would not scale as a
> solution. If we were to make it a convention to pass something from
> the very top of the call chain everywhere, it should not be an
> individual variable that is overly specific, like comment_line_str.
> Rather, it has to be something that allows access to a bag of all
> the global settings (possibly wider than "the_repository" struct).
> We can also limit our reliance to the globals by allowing a single
> global function call to obtaion such a bag of all global settings,
> i.e. "get_the_environment()", and allow everybody, including
> functions at the leaf level, to ask "what is the comment_line_str in
> the environment I am working in?". As part of the libification, we
> can plug in an appropriate shim for get_the_environment().
This here I can definitely agree with. I think the best fit we have in
general is the "repo-settings.c" subsystem, which is also where I've
moved some of the previously-global settings into. It still has some
downsides in its current format:
- It depends on a repository, but I'd argue it shouldn't such that we
can also query configuration in repo-less settings.
- `prepare_repo_settings()` makes up for a bad calling convention. I
think that lazy accessors are way easier to use.
But it is a start, and something we can continue to build on.
Patrick
^ permalink raw reply
* Re: [PATCH 2/2] Git.pm: use "rev-parse --absolute-git-dir" rather than perl code
From: Patrick Steinhardt @ 2024-09-13 6:05 UTC (permalink / raw)
To: Jeff King; +Cc: Rodrigo, git
In-Reply-To: <20240912223725.GB650605@coredump.intra.peff.net>
On Thu, Sep 12, 2024 at 06:37:25PM -0400, Jeff King wrote:
> When we open a repository with the "Directory" option, we use "rev-parse
> --git-dir" to get the path relative to that directory, and then use
> Cwd::abs_path() to make it absolute (since our process working directory
> may not be the same).
>
> These days we can just ask for "--absolute-git-dir" instead, which saves
> us a little code. That option was added in Git v2.13.0 via a2f5a87626
> (rev-parse: add '--absolute-git-dir' option, 2017-02-03). I don't think
> we make any promises about running mismatched versions of git and
> Git.pm, but even if somebody tries it, that's sufficiently old that it
> should be OK.
Agreed. We should eventually be able to rely on things that we have
implemented many years ago.
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I retained the "require Cwd" here since we use it in the conditional
> (but moved it closer to the point of use). It's not strictly necessary,
> as earlier code will have required it as a side effect, but it's
> probably best not to rely on that.
>
> perl/Git.pm | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/perl/Git.pm b/perl/Git.pm
> index cf1ef0b32a..667152c6c6 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -187,7 +187,7 @@ sub repository {
> try {
> # Note that "--is-bare-repository" must come first, as
> # --git-dir output could contain newlines.
> - $out = $search->command([qw(rev-parse --is-bare-repository --git-dir)],
> + $out = $search->command([qw(rev-parse --is-bare-repository --absolute-git-dir)],
> STDERR => 0);
> } catch Git::Error::Command with {
> throw Error::Simple("fatal: not a git repository: $opts{Directory}");
> @@ -196,12 +196,12 @@ sub repository {
> chomp $out;
> my ($bare, $dir) = split /\n/, $out, 2;
This line here made me think for a second what happens if the absolute
path contains newlines. But it should be fine, because we only split at
the first newline character we find. And as the first parameter that we
pass to git-rev-parse(1) is `--is-bare-repository`, we know that it will
output either `true` or `false` as the first line. Any subsequent
newlines should thus be handled alright.
Patrick
^ permalink raw reply
* Re: [PATCH 1/2] Git.pm: fix bare repository search with Directory option
From: Patrick Steinhardt @ 2024-09-13 6:05 UTC (permalink / raw)
To: Jeff King; +Cc: Rodrigo, git
In-Reply-To: <20240912223604.GA650605@coredump.intra.peff.net>
On Thu, Sep 12, 2024 at 06:36:04PM -0400, Jeff King wrote:
> diff --git a/perl/Git.pm b/perl/Git.pm
> index aebfe0c6e0..cf1ef0b32a 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -197,11 +197,11 @@ sub repository {
> my ($bare, $dir) = split /\n/, $out, 2;
>
> require Cwd;
> - if ($bare ne 'true') {
> - require File::Spec;
> - File::Spec->file_name_is_absolute($dir) or $dir = $opts{Directory} . '/' . $dir;
> - $opts{Repository} = Cwd::abs_path($dir);
> + require File::Spec;
> + File::Spec->file_name_is_absolute($dir) or $dir = $opts{Directory} . '/' . $dir;
> + $opts{Repository} = Cwd::abs_path($dir);
>
> + if ($bare ne 'true') {
> # If --git-dir went ok, this shouldn't die either.
> my $prefix = $search->command_oneline('rev-parse', '--show-prefix');
> $dir = Cwd::abs_path($opts{Directory}) . '/';
> @@ -214,8 +214,6 @@ sub repository {
> $opts{WorkingCopy} = $dir;
> $opts{WorkingSubdir} = $prefix;
>
> - } else {
> - $opts{Repository} = Cwd::abs_path($dir);
> }
>
> delete $opts{Directory};
Makes sense. We already knew that the $dir was relative, but only
remembered to handle this in case the repository was non-bare. Now both
cases use the same code to translate the relative path to an absolute
one.
> diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
> index ccc8212d73..4431697122 100755
> --- a/t/t9700-perl-git.sh
> +++ b/t/t9700-perl-git.sh
> @@ -45,7 +45,8 @@ test_expect_success 'set up test repository' '
> '
>
> test_expect_success 'set up bare repository' '
> - git init --bare bare.git
> + git init --bare bare.git &&
> + git -C bare.git --work-tree=. commit --allow-empty -m "bare commit"
> '
>
> test_expect_success 'use t9700/test.pl to test Git.pm' '
I didn't even know that this hack was possible. I guess the alternative
would be to use git-commit-tree(1) with the empty tree ID, but that'd
also require us to update branches manually via git-update-ref(1). So...
a bit gross, but hey, if it works...
Patrick
^ permalink raw reply
* [PATCH 5/4] ci: add Ubuntu 16.04 job to GitLab CI
From: Patrick Steinhardt @ 2024-09-13 5:52 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <20240912094238.GA589050@coredump.intra.peff.net>
In the preceding commits we had to convert the linux32 job to be based
on Ubuntu 20.04 instead of Ubuntu 16.04 due to a limitation in GitHub
Workflows. This was the only job left that still tested against this old
but supported Ubuntu version, and we have no other jobs that test with a
comparatively old Linux distribution.
Add a new job to GitLab CI that tests with Ubuntu 16.04 to cover the
resulting test gap. GitLab doesn't modify Docker images in the same way
GitHub does and thus doesn't fall prey to the same issue. There are two
compatibility issues uncovered by this:
- Ubuntu 16.04 does not support HTTP/2 in Apache. We thus cannot set
`GIT_TEST_HTTPD=true`, which would otherwise cause us to fail when
Apache fails to start.
- Ubuntu 16.04 cannot use recent JGit versions as they depend on a
more recent Java runtime than we have available. We thus disable
installing any kind of optional dependencies that do not come from
the package manager.
These two restrictions are fine though, as we only really care about
whether Git compiles and runs on such old distributions in the first
place.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Test runs of this can be found at [1]. Note that the Alpine Linux jobs
fail, due to an upstream regression in libcurl [2].
[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/210
[2]: <ZuPKvYP9ZZ2mhb4m@pks.im>
.gitlab-ci.yml | 3 +++
ci/install-dependencies.sh | 5 +++++
ci/lib.sh | 9 ++++++++-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 2589098eff7..80b1668ebeb 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -25,6 +25,9 @@ test:linux:
fi
parallel:
matrix:
+ - jobname: linux-old
+ image: ubuntu:16.04
+ CC: gcc
- jobname: linux-sha256
image: ubuntu:latest
CC: clang
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 735ee6f4639..08656a15308 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -55,6 +55,11 @@ ubuntu-*|ubuntu32-*)
${CC_PACKAGE:-${CC:-gcc}} $PYTHON_PACKAGE
case "$distro" in
+ ubuntu-16.04)
+ # Does not support JGit, but we also don't really care about
+ # the others. We rather care whether Git still compiles and
+ # runs fine overall.
+ ;;
ubuntu-*)
mkdir --parents "$CUSTOM_PATH"
diff --git a/ci/lib.sh b/ci/lib.sh
index 51f8f59a296..74b430be238 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -336,7 +336,14 @@ ubuntu-*)
fi
MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE"
- export GIT_TEST_HTTPD=true
+ case "$distro" in
+ ubuntu-16.04)
+ # Apache is too old for HTTP/2.
+ ;;
+ *)
+ export GIT_TEST_HTTPD=true
+ ;;
+ esac
# The Linux build installs the defined dependency versions below.
# The OS X build installs much more recent versions, whichever
base-commit: f33406dbcc16e699be71aa4982133c325838ae1b
--
2.46.0.551.gc5ee8f2d1c.dirty
^ permalink raw reply related
* Re: [PATCH 3/4] ci: use more recent linux32 image
From: Patrick Steinhardt @ 2024-09-13 5:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20240913045510.GA1194807@coredump.intra.peff.net>
On Fri, Sep 13, 2024 at 12:55:10AM -0400, Jeff King wrote:
> On Thu, Sep 12, 2024 at 02:47:38PM +0200, Patrick Steinhardt wrote:
>
> > On Thu, Sep 12, 2024 at 01:53:00PM +0200, Patrick Steinhardt wrote:
> > > On Thu, Sep 12, 2024 at 07:22:42AM -0400, Jeff King wrote:
> > > > On Thu, Sep 12, 2024 at 12:41:03PM +0200, Patrick Steinhardt wrote:
> > > And with that the [fixed] pipeline builds and executes our tests just
> > > fine. I didn't wait for tests to finish though.
> > >
> > > Patrick
> > >
> > > [here]: https://gitlab.com/gitlab-org/git/-/merge_requests/210
> > > [first]: https://gitlab.com/gitlab-org/git/-/jobs/7808775485
> > > [fixed]: https://gitlab.com/gitlab-org/git/-/jobs/7808836999
> >
> > Most of the tests pass, except for t5559. Seems like it doesn't have
> > mod_http2. Maybe its Apache version is too old, or it needs to be
> > installed separately.
>
> Yeah, according to "apt-file", there's no package which contains
> mod_http2.so. t5559 is supposed to notice that during webserver setup
> and just skip the script. Poking at it myself in a xenial container, I
> think it does do so correctly. So that's good.
>
> But the CI environment switches GIT_TEST_HTTPD from "auto" to "true",
> turning a setup failure into an error. This is overall a good thing
> (since we'd notice if our apache setup breaks), but obviously is wrong
> here. Unfortunately we don't have a knob just for http2. So the best we
> can do is something like (might be whitespace-damaged, I just pasted it
> out of a container session):
>
> diff --git a/ci/lib.sh b/ci/lib.sh
> index 51f8f59..0514f6a 100755
> --- a/ci/lib.sh
> +++ b/ci/lib.sh
> @@ -336,7 +336,15 @@ ubuntu-*)
> fi
> MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE"
>
> - export GIT_TEST_HTTPD=true
> + case "$distro" in
> + ubuntu-16.04)
> + # too old for http/2
> + export GIT_TEST_HTTPD=auto
> + ;;
> + *)
> + export GIT_TEST_HTTPD=yes
> + ;;
> + esac
>
> # The Linux build installs the defined dependency versions below.
> # The OS X build installs much more recent versions, whichever
>
>
> That would still run the regular tests, and just turn the http2 failure
> into a "skip". But it does make me nervous that we'd break something for
> the non-http2 tests on that old platform and never realize it. So maybe
> we need a GIT_TEST_HTTP2 knob that defaults to the value of
> GIT_TEST_HTTPD. And then we can turn it off for 16.04, leave the regular
> one as "yes".
>
> I assume you're collecting a few patches to make your new xenial job
> work. I think what I suggested above should be pretty easy to implement,
> but let me know if you'd like me to come up with something concrete.
Yeah, that does the job, thanks. Let me tie all of this into a neat
package and post it as 5/4 on top of this patch series.
Patrick
^ permalink raw reply
* curl 8.10.0 regression breaks uploads with HTTP/2 and http.postbuffer
From: Patrick Steinhardt @ 2024-09-13 5:16 UTC (permalink / raw)
To: git; +Cc: Daniel Stenberg
Hi,
I noticed that GitLab's CI started to fail consistently with our
Alpine-based builds in t5559.30. After investigating a bit I couldn't
notice anything obvious on our side changing, so I checked whether
Alpine itself updated any packages. And indeed, it updated to curl 8.10
yesterday.
I first expected this to be musl-specific, but I can reproduce the issue
on my glibc system, as well. The issue bisects to 35bf76628 (http2:
improved upload eos handling, 2024-08-04), which checks out with the
symptoms.
Reproducer in the Git project:
```
$ make
$ cd t/
$ ./t5559-http-fetch-smart-http2.sh --run=1-4,30 -ix
```
Apache logs:
[Fri Sep 13 05:10:57.153872 2024] [ssl:warn] [pid 1435033:tid 1435033] AH01909: dummy:443:0 server certificate does NOT include an ID which matches the server name
[Fri Sep 13 05:10:57.156090 2024] [ssl:warn] [pid 1435035:tid 1435035] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache]
[Fri Sep 13 05:10:57.157052 2024] [ssl:warn] [pid 1435035:tid 1435035] AH01909: dummy:443:0 server certificate does NOT include an ID which matches the server name
[Fri Sep 13 05:10:57.158122 2024] [mpm_event:notice] [pid 1435035:tid 1435035] AH00489: Apache/2.4.62 (Unix) OpenSSL/3.0.14 configured -- resuming normal operations
[Fri Sep 13 05:10:57.158140 2024] [core:notice] [pid 1435035:tid 1435035] AH00094: Command line: '/nix/store/r2vzwkm8xvzdkfyqc9m3b3cc6q6jdly4-apache-httpd-2.4.62/bin/httpd -d /tmp/git-tests/trash directory.t5559-http-fetch-smart-http2/httpd -f /home/pks/Development/git/t/lib-httpd/apache.conf -D HTTP2 -D SSL -c Listen 127.0.0.1:5559'
[Fri Sep 13 05:11:57.434888 2024] [cgi:error] [pid 1435039:tid 1435046] (70007)The timeout specified has expired: [remote 127.0.0.1:53154] AH01225: Error reading request entity data
[Fri Sep 13 05:11:57.545789 2024] [mpm_event:notice] [pid 1435035:tid 1435035] AH00491: caught SIGTERM, shutting down
Most lines are expected, but the second-to-last line mentions an expired
timeout. So I suspect that with the mentioned commit, curl does not
detect the EOS correctly in all scenarios anymore. This only happens
with HTTP/2 -- the tests continue to work just fine with HTTP/1, which
we execute via t5551.
I didn't dig much further than that.
Patrick
^ permalink raw reply
* Re: [PATCH 3/4] ci: use more recent linux32 image
From: Jeff King @ 2024-09-13 4:55 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Junio C Hamano, git
In-Reply-To: <ZuLi4x664v8dbm2i@pks.im>
On Thu, Sep 12, 2024 at 02:47:38PM +0200, Patrick Steinhardt wrote:
> On Thu, Sep 12, 2024 at 01:53:00PM +0200, Patrick Steinhardt wrote:
> > On Thu, Sep 12, 2024 at 07:22:42AM -0400, Jeff King wrote:
> > > On Thu, Sep 12, 2024 at 12:41:03PM +0200, Patrick Steinhardt wrote:
> > And with that the [fixed] pipeline builds and executes our tests just
> > fine. I didn't wait for tests to finish though.
> >
> > Patrick
> >
> > [here]: https://gitlab.com/gitlab-org/git/-/merge_requests/210
> > [first]: https://gitlab.com/gitlab-org/git/-/jobs/7808775485
> > [fixed]: https://gitlab.com/gitlab-org/git/-/jobs/7808836999
>
> Most of the tests pass, except for t5559. Seems like it doesn't have
> mod_http2. Maybe its Apache version is too old, or it needs to be
> installed separately.
Yeah, according to "apt-file", there's no package which contains
mod_http2.so. t5559 is supposed to notice that during webserver setup
and just skip the script. Poking at it myself in a xenial container, I
think it does do so correctly. So that's good.
But the CI environment switches GIT_TEST_HTTPD from "auto" to "true",
turning a setup failure into an error. This is overall a good thing
(since we'd notice if our apache setup breaks), but obviously is wrong
here. Unfortunately we don't have a knob just for http2. So the best we
can do is something like (might be whitespace-damaged, I just pasted it
out of a container session):
diff --git a/ci/lib.sh b/ci/lib.sh
index 51f8f59..0514f6a 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -336,7 +336,15 @@ ubuntu-*)
fi
MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE"
- export GIT_TEST_HTTPD=true
+ case "$distro" in
+ ubuntu-16.04)
+ # too old for http/2
+ export GIT_TEST_HTTPD=auto
+ ;;
+ *)
+ export GIT_TEST_HTTPD=yes
+ ;;
+ esac
# The Linux build installs the defined dependency versions below.
# The OS X build installs much more recent versions, whichever
That would still run the regular tests, and just turn the http2 failure
into a "skip". But it does make me nervous that we'd break something for
the non-http2 tests on that old platform and never realize it. So maybe
we need a GIT_TEST_HTTP2 knob that defaults to the value of
GIT_TEST_HTTPD. And then we can turn it off for 16.04, leave the regular
one as "yes".
I assume you're collecting a few patches to make your new xenial job
work. I think what I suggested above should be pretty easy to implement,
but let me know if you'd like me to come up with something concrete.
-Peff
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox