git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/9] bundle-uri client: add minimal NOOP client

From
Victoria Dye <vdye@github.com>
Date
Nov 29, 2022, 00:57 UTC
Message-ID
<ca410bed-e8d1-415f-5235-b64fe18bed27@github.com>
In-Reply-To
<0d85aef965d62a684b25f388a946abd3c17809fc.1668628303.git.gitgitgadget@gmail.com>
Ævar Arnfjörð Bjarmason via GitGitGadget wrote:
Show 15 quoted lines
> From: =?UTF-8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?=
>  <avarab@gmail.com>
> 
> Set up all the needed client parts of the "bundle-uri" protocol
> extension, without actually doing anything with the bundle URIs.
> 
> I.e. if the server says it supports "bundle-uri" we'll issue a
> command=bundle-uri after command=ls-refs when we're cloning. We'll
> parse the returned output using the code already tested for in
> t5750-bundle-uri-parse.sh.
> 
> What we aren't doing is actually acting on that data, i.e. downloading
> the bundle(s) before we get to doing the command=fetch, and adjusting
> our negotiation dialog appropriately. I'll do that in subsequent
> commits.
Makes sense.
Show 5 quoted lines
> 
> There's a question of what level of encapsulation we should use here,
> I've opted to use connect.h in clone.c, but we could also e.g. make
> transport_get_remote_refs() invoke this, i.e. make it implicitly get
> the bundle-uri list for later steps.

I'm not sure I follow what this sentence is saying. Looking at the implementation below [1], you've added a call to 'transport_get_remote_bundle_uri()' in 'clone.c', but that's defined in 'transport.h' (which is already included in 'clone.c'). Why is 'connect.h' needed at all?

Show 5 quoted lines
> 
> This approach means that we don't "support" this in "git fetch" for
> now. I'm starting with the case of initial clones, although as noted
> in preceding commits to the protocol documentation nothing about this
> approach precludes getting bundles on incremental fetches.

This explanation seems more complicated than necessary. I think it's sufficient to say "The no-op client is initially used only in 'clone' to test the basic functionality. The bundle URI client will be integrated into fetch, pull, etc. in later patches".

Show 5 quoted lines
> 
> For the t5732-protocol-v2-bundle-uri-http.sh it's not easy to set
> environment variables for git-upload-pack (it's started by Apache), so
> let's skip the test under T5730_HTTP, and add unused T5730_{FILE,GIT}
> prerequisites for consistency and future use.

"skip the test" doesn't explain *which* test is skipped (and it doesn't look like you skip all of them). I think you're referring to "bad client with $T5730_PROTOCOL:// using protocol v2" specifically?

Show 43 quoted lines
> 
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
> ---
>  builtin/clone.c                        |   7 ++
>  bundle-uri.c                           |   4 +
>  connect.c                              |  47 ++++++++
>  remote.h                               |   5 +
>  t/lib-t5730-protocol-v2-bundle-uri.sh  | 148 +++++++++++++++++++++++++
>  t/t5730-protocol-v2-bundle-uri-file.sh |  36 ++++++
>  t/t5731-protocol-v2-bundle-uri-git.sh  |  17 +++
>  t/t5732-protocol-v2-bundle-uri-http.sh |  17 +++
>  transport-helper.c                     |  13 +++
>  transport-internal.h                   |   7 ++
>  transport.c                            |  55 +++++++++
>  transport.h                            |  19 ++++
>  12 files changed, 375 insertions(+)
>  create mode 100644 t/lib-t5730-protocol-v2-bundle-uri.sh
>  create mode 100755 t/t5730-protocol-v2-bundle-uri-file.sh
>  create mode 100755 t/t5731-protocol-v2-bundle-uri-git.sh
>  create mode 100755 t/t5732-protocol-v2-bundle-uri-http.sh
> 
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 547d6464b3c..edf98295af2 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -27,6 +27,7 @@
>  #include "iterator.h"
>  #include "sigchain.h"
>  #include "branch.h"
> +#include "connect.h"
>  #include "remote.h"
>  #include "run-command.h"
>  #include "connected.h"
> @@ -1266,6 +1267,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>  	if (refs)
>  		mapped_refs = wanted_peer_refs(refs, &remote->fetch);
>  
> +	/*
> +	 * Populate transport->got_remote_bundle_uri and
> +	 * transport->bundle_uri. We might get nothing.
> +	 */
> +	transport_get_remote_bundle_uri(transport);
[1]
Show 15 quoted lines
> +
>  	if (mapped_refs) {
>  		int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
>  
> diff --git a/bundle-uri.c b/bundle-uri.c
> index 32022595964..2201b604b11 100644
> --- a/bundle-uri.c
> +++ b/bundle-uri.c
> @@ -571,6 +571,10 @@ int bundle_uri_advertise(struct repository *r, struct strbuf *value)
>  {
>  	static int advertise_bundle_uri = -1;
>  
> +	if (value &&
> +	    git_env_bool("GIT_TEST_BUNDLE_URI_UNKNOWN_CAPABILITY_VALUE", 0))
> +		strbuf_addstr(value, "test-unknown-capability-value");

It looks like 'GIT_TEST_BUNDLE_URI_UNKNOWN_CAPABILITY_VALUE' is being used to "mock" server responses to test certain behavior on the client side. I'm somewhat uncomfortable with how this mixes test-specific code paths with application code, and AFAICT nothing similar is done for other advertise/command functions in protocol v2. Is there a way to set up tests to intercept the client requests and customize the response?

Show 38 quoted lines
> +
>  	if (advertise_bundle_uri != -1)
>  		goto cached;
>  
> diff --git a/connect.c b/connect.c
> index 5ea53deda23..d39effb7492 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -15,6 +15,7 @@
>  #include "version.h"
>  #include "protocol.h"
>  #include "alias.h"
> +#include "bundle-uri.h"
>  
>  static char *server_capabilities_v1;
>  static struct strvec server_capabilities_v2 = STRVEC_INIT;
> @@ -491,6 +492,52 @@ static void send_capabilities(int fd_out, struct packet_reader *reader)
>  	}
>  }
>  
> +int get_remote_bundle_uri(int fd_out, struct packet_reader *reader,
> +			  struct bundle_list *bundles, int stateless_rpc)
> +{
> +	int line_nr = 1;
> +
> +	/* Assert bundle-uri support */
> +	server_supports_v2("bundle-uri", 1);
> +
> +	/* (Re-)send capabilities */
> +	send_capabilities(fd_out, reader);
> +
> +	/* Send command */
> +	packet_write_fmt(fd_out, "command=bundle-uri\n");
> +	packet_delim(fd_out);
> +
> +	/* Send options */
> +	if (git_env_bool("GIT_TEST_PROTOCOL_BAD_BUNDLE_URI", 0))
> +		packet_write_fmt(fd_out, "test-bad-client\n");

Same comment as on 'GIT_TEST_BUNDLE_URI_UNKNOWN_CAPABILITY_VALUE'. There's no precedent that I can find for a test variable like this in 'connect.c', and "in the middle of client code" doesn't seem like an ideal place for it.

If there really isn't another way of doing this, could the addition of these 'GIT_TEST' variables and their associated tests be split out into a dedicated commit? That would at least separate the test code paths from the application code in the commit history.

Show 26 quoted lines
> +	packet_flush(fd_out);
> +
> +	/* Process response from server */
> +	while (packet_reader_read(reader) == PACKET_READ_NORMAL) {
> +		const char *line = reader->line;
> +		line_nr++;
> +
> +		if (!bundle_uri_parse_line(bundles, line))
> +			continue;
> +
> +		return error(_("error on bundle-uri response line %d: %s"),
> +			     line_nr, line);
> +	}
> +
> +	if (reader->status != PACKET_READ_FLUSH)
> +		return error(_("expected flush after bundle-uri listing"));
> +
> +	/*
> +	 * Might die(), but obscure enough that that's OK, e.g. in
> +	 * serve.c we'll call BUG() on its equivalent (the
> +	 * PACKET_READ_RESPONSE_END check).
> +	 */
> +	check_stateless_delimiter(stateless_rpc, reader,
> +				  _("expected response end packet after ref listing"));
> +
> +	return 0;
The rest of this looks fine to me.
Show 10 quoted lines
> +}
> +
>  struct ref **get_remote_refs(int fd_out, struct packet_reader *reader,
>  			     struct ref **list, int for_push,
>  			     struct transport_ls_refs_options *transport_options,
> diff --git a/t/lib-t5730-protocol-v2-bundle-uri.sh b/t/lib-t5730-protocol-v2-bundle-uri.sh
> new file mode 100644
> index 00000000000..27294e9c976
> --- /dev/null
> +++ b/t/lib-t5730-protocol-v2-bundle-uri.sh

nit: this set of tests is used in more than just 't5730', so the name is somewhat misleading. It also seems a bit overly-specific to include "protocol-v2" in the filename (the tests themselves mention "protocol v2" when it's relevant). What about something like 'lib-proto-bundle-uri.sh' (using "proto" to mimic 'lib-proto-disable.sh')?

Show 6 quoted lines
> @@ -0,0 +1,148 @@
> +# Included from t573*-protocol-v2-bundle-uri-*.sh
> +
> +T5730_PARENT=
> +T5730_URI=
> +T5730_BUNDLE_URI=

Similar to the filename nit - these variables are used in tests outside of 't5730', so their names are not quite accurate to their usage.

Show 6 quoted lines
> +# Poor man's URI escaping. Good enough for the test suite whose trash
> +# directory has a space in it. See 93c3fcbe4d4 (git-svn: attempt to
> +# mimic SVN 1.7 URL canonicalization, 2012-07-28) for prior art.
> +test_uri_escape() {
> +	sed 's/ /%20/g'
> +}

This is a good opportunity to unify on a single implementation rather than to have multiple similar ones floating around. Can this be moved into 'test-lib.sh' (or 'test-lib-functions.sh'?), with 't9119' and 't9120' updated to use the new 'test_uri_escape()'?

Show 23 quoted lines
> diff --git a/t/t5730-protocol-v2-bundle-uri-file.sh b/t/t5730-protocol-v2-bundle-uri-file.sh
> new file mode 100755
> index 00000000000..89203d3a23c
> --- /dev/null
> +++ b/t/t5730-protocol-v2-bundle-uri-file.sh
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +
> +test_description="Test bundle-uri with protocol v2 and 'file://' transport"
> +
> +TEST_NO_CREATE_REPO=1
> +
> +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
> +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
> +
> +. ./test-lib.sh
> +
> +# Test protocol v2 with 'file://' transport
> +#
> +T5730_PROTOCOL=file
> +. "$TEST_DIRECTORY"/lib-t5730-protocol-v2-bundle-uri.sh
> +
> +test_expect_success "unknown capability value with $T5730_PROTOCOL:// using protocol v2" '

Why is this test only run for the 'file://' transport protocol? And, why isn't it in 'lib-t5730-protocol-v2-bundle-uri.sh'? If nothing else, moving this test to that file (even if it needs to be conditional on a specific protocol) puts the '$T5730_PARENT', '$T5730_BUNDLE_URI_ESCAPED' and '$T5730_URI' variables in scope for better readability.

Show 11 quoted lines
> +	test_when_finished "rm -f log" &&
> +
> +	test_config -C "$T5730_PARENT" \
> +		uploadpack.bundleURI "$T5730_BUNDLE_URI_ESCAPED" &&
> +
> +	GIT_TRACE_PACKET="$PWD/log" \
> +	GIT_TEST_BUNDLE_URI_UNKNOWN_CAPABILITY_VALUE=true \
> +	git \
> +		-c protocol.version=2 \
> +		ls-remote --symref "$T5730_URI" \
> +		>actual 2>err &&

This test never does anything with the content of 'actual' or 'err'. Should it? If not, they probably shouldn't be redirected from stdout/stderr, since the messages might be valuable when debugging.

Show 47 quoted lines
> +
> +	# Server responded using protocol v2
> +	grep "< version 2" log &&
> +
> +	grep "> bundle-uri=test-unknown-capability-value" log
> +'
> +
> +test_done
> diff --git a/transport-helper.c b/transport-helper.c
> index e95267a4ab5..3ea7c2bb5ad 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -1267,9 +1267,22 @@ static struct ref *get_refs_list_using_list(struct transport *transport,
>  	return ret;
>  }
>  
> +static int get_bundle_uri(struct transport *transport)
> +{
> +	get_helper(transport);
> +
> +	if (process_connect(transport, 0)) {
> +		do_take_over(transport);
> +		return transport->vtable->get_bundle_uri(transport);
> +	}
> +
> +	return -1;
> +}
> +
>  static struct transport_vtable vtable = {
>  	.set_option	= set_helper_option,
>  	.get_refs_list	= get_refs_list,
> +	.get_bundle_uri = get_bundle_uri,
>  	.fetch_refs	= fetch_refs,
>  	.push_refs	= push_refs,
>  	.connect	= connect_helper,
> diff --git a/transport-internal.h b/transport-internal.h
> index c4ca0b733ac..90ea749e5cf 100644
> --- a/transport-internal.h
> +++ b/transport-internal.h
> @@ -26,6 +26,13 @@ struct transport_vtable {
>  	struct ref *(*get_refs_list)(struct transport *transport, int for_push,
>  				     struct transport_ls_refs_options *transport_options);
>  
> +	/**
> +	 * Populates the remote side's bundle-uri under protocol v2,
> +	 * if the "bundle-uri" capability was advertised. Returns 0 if
> +	 * OK, negative values on error.

Double-checked the call stack to make sure this is true, and it is (the return value is always either a hardcoded '0' or 'error()'.

Show 26 quoted lines
> +	 */
> +	int (*get_bundle_uri)(struct transport *transport);
> +
>  	/**
>  	 * Fetch the objects for the given refs. Note that this gets
>  	 * an array, and should ignore the list structure.
> diff --git a/transport.c b/transport.c
> index e7b97194c10..a020adc1f56 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -902,6 +922,7 @@ static int disconnect_git(struct transport *transport)
>  
>  static struct transport_vtable taken_over_vtable = {
>  	.get_refs_list	= get_refs_via_connect,
> +	.get_bundle_uri = get_bundle_uri,
>  	.fetch_refs	= fetch_refs_via_pack,
>  	.push_refs	= git_transport_push,
>  	.disconnect	= disconnect_git
> @@ -1054,6 +1075,7 @@ static struct transport_vtable bundle_vtable = {
>  
>  static struct transport_vtable builtin_smart_vtable = {
>  	.get_refs_list	= get_refs_via_connect,
> +	.get_bundle_uri = get_bundle_uri,
>  	.fetch_refs	= fetch_refs_via_pack,
>  	.push_refs	= git_transport_push,
>  	.connect	= connect_git,

I think I follow what this is doing (if I'm reading correctly) - add 'get_bundle_uri' to all of the vtables (including in 'transport-helper.c') *except* 'bundle_vtable', since we aren't requesting bundle URIs from an already-identified bundle URI.

Show 11 quoted lines
> @@ -1482,6 +1507,34 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs)
>  	return rc;
>  }
>  
> +int transport_get_remote_bundle_uri(struct transport *transport)
> +{
> +	const struct transport_vtable *vtable = transport->vtable;
> +
> +	/* Check config only once. */
> +	if (transport->got_remote_bundle_uri++)
> +		return 0;

We're only ever going to read the bundle list once per command (or, at least once per 'transport' instance), so if 'transport_get_remote_bundle_uri()' has already been called, we can safely assume the correct results (if any) are in the 'transport' structure.

Show 17 quoted lines
> +
> +	/*
> +	 * "Support" protocol v0 and v2 without bundle-uri support by
> +	 * silently degrading to a NOOP.
> +	 */
> +	if (!server_supports_v2("bundle-uri", 0))
> +		return 0;
> +
> +	/*
> +	 * This is intentionally below the transport.injectBundleURI,
> +	 * we want to be able to inject into protocol v0, or into the
> +	 * dialog of a server who doesn't support this.
> +	 */
> +	if (!vtable->get_bundle_uri)
> +		return error(_("bundle-uri operation not supported by protocol"));
> +
> +	if (vtable->get_bundle_uri(transport) < 0)

As you noted earlier, 'get_bundle_uri()' always returns a value <= 0, so this check works.

Show 7 quoted lines
> +		return error(_("could not retrieve server-advertised bundle-uri list"));
> +	return 0;
> +}
> +
>  void transport_unlock_pack(struct transport *transport, unsigned int flags)
>  {
>  	int in_signal_handler = !!(flags & TRANSPORT_UNLOCK_PACK_IN_SIGNAL_HANDLER)
Previous: Ævar Arnfjörð Bjarmason via GitGitGadgetNext: Derrick Stolee
Message 22 of 87 in “Bundle URIs IV: advertise over protocol v2”
  1. 0/9 Bundle URIs IV: advertise over protocol v2Derrick Stolee via GitGitGadget, Nov 1, 2022
  2. 1/9 protocol v2: add server-side "bundle-uri" skeletonÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 1, 2022
  3. SZEDER GáborNov 8, 2022
  4. Victoria DyeNov 11, 2022
  5. Derrick StoleeNov 16, 2022
  6. 2/9 bundle-uri client: add minimal NOOP clientÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 1, 2022
  7. 3/9 bundle-uri client: add helper for testing serverÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 1, 2022
  8. 4/9 bundle-uri: serve bundle.* keys from configDerrick Stolee via GitGitGadget, Nov 1, 2022
  9. 5/9 bundle-uri client: add boolean transfer.bundleURI settingÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 1, 2022
  10. 6/9 strbuf: reintroduce strbuf_parent_directory()Derrick Stolee via GitGitGadget, Nov 1, 2022
  11. Phillip WoodNov 3, 2022
  12. Ævar Arnfjörð BjarmasonNov 3, 2022
  13. 8/9 bundle-uri: download bundles from an advertised listDerrick Stolee via GitGitGadget, Nov 1, 2022
  14. 7/9 bundle-uri: allow relative URLs in bundle listsDerrick Stolee via GitGitGadget, Nov 1, 2022
  15. 9/9 clone: unbundle the advertised bundlesDerrick Stolee via GitGitGadget, Nov 1, 2022
  16. 0/9 Bundle URIs IV: advertise over protocol v2Derrick Stolee via GitGitGadget, Nov 16, 2022
  17. 1/9 protocol v2: add server-side "bundle-uri" skeletonÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 16, 2022
  18. 3/9 bundle-uri client: add helper for testing serverÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 16, 2022
  19. Victoria DyeNov 29, 2022
  20. Derrick StoleeDec 2, 2022
  21. 2/9 bundle-uri client: add minimal NOOP clientÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 16, 2022
  22. Victoria DyeNov 29, 2022
  23. Derrick StoleeDec 2, 2022
  24. 6/9 strbuf: introduce strbuf_strip_file_from_path()Derrick Stolee via GitGitGadget, Nov 16, 2022
  25. Victoria DyeNov 29, 2022
  26. Derrick StoleeDec 2, 2022
  27. Ævar Arnfjörð BjarmasonDec 2, 2022
  28. Derrick StoleeDec 5, 2022
  29. 5/9 bundle-uri client: add boolean transfer.bundleURI settingÆvar Arnfjörð Bjarmason via GitGitGadget, Nov 16, 2022
  30. Victoria DyeNov 29, 2022
  31. Derrick StoleeDec 2, 2022
  32. 8/9 bundle-uri: download bundles from an advertised listDerrick Stolee via GitGitGadget, Nov 16, 2022
  33. Victoria DyeNov 29, 2022
  34. 7/9 bundle-uri: allow relative URLs in bundle listsDerrick Stolee via GitGitGadget, Nov 16, 2022
  35. Victoria DyeNov 29, 2022
  36. Derrick StoleeDec 2, 2022
  37. 4/9 bundle-uri: serve bundle.* keys from configDerrick Stolee via GitGitGadget, Nov 16, 2022
  38. Victoria DyeNov 29, 2022
  39. 9/9 clone: unbundle the advertised bundlesDerrick Stolee via GitGitGadget, Nov 16, 2022
  40. Victoria DyeNov 29, 2022
  41. Derrick StoleeDec 2, 2022
  42. 00/11 Bundle URIs IV: advertise over protocol v2Derrick Stolee via GitGitGadget, Dec 5, 2022
  43. 10/11 bundle-uri: download bundles from an advertised listDerrick Stolee via GitGitGadget, Dec 5, 2022
  44. Jeff KingDec 7, 2022
  45. Derrick StoleeDec 7, 2022
  46. Derrick StoleeDec 7, 2022
  47. Jeff KingDec 8, 2022
  48. Jeff KingDec 8, 2022
  49. Derrick StoleeDec 8, 2022
  50. 09/11 bundle-uri: allow relative URLs in bundle listsDerrick Stolee via GitGitGadget, Dec 5, 2022
  51. Victoria DyeDec 5, 2022
  52. Derrick StoleeDec 7, 2022
  53. 01/11 protocol v2: add server-side "bundle-uri" skeletonÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 5, 2022
  54. Victoria DyeDec 5, 2022
  55. 07/11 bundle-uri: serve bundle.* keys from configDerrick Stolee via GitGitGadget, Dec 5, 2022
  56. 04/11 bundle-uri client: add boolean transfer.bundleURI settingÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 5, 2022
  57. Victoria DyeDec 5, 2022
  58. Derrick StoleeDec 7, 2022
  59. 02/11 t: create test harness for 'bundle-uri' commandÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 5, 2022
  60. 11/11 clone: unbundle the advertised bundlesDerrick Stolee via GitGitGadget, Dec 5, 2022
  61. 06/11 bundle-uri client: add helper for testing serverÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 5, 2022
  62. Victoria DyeDec 5, 2022
  63. 03/11 clone: request the 'bundle-uri' command when availableÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 5, 2022
  64. 08/11 strbuf: introduce strbuf_strip_file_from_path()Derrick Stolee via GitGitGadget, Dec 5, 2022
  65. Ævar Arnfjörð BjarmasonDec 6, 2022
  66. Ævar Arnfjörð BjarmasonDec 6, 2022
  67. Derrick StoleeDec 7, 2022
  68. Ævar Arnfjörð BjarmasonDec 8, 2022
  69. 05/11 transport: rename got_remote_headsDerrick Stolee via GitGitGadget, Dec 5, 2022
  70. Victoria DyeDec 5, 2022
  71. 00/11 Bundle URIs IV: advertise over protocol v2Derrick Stolee via GitGitGadget, Dec 22, 2022
  72. 01/11 protocol v2: add server-side "bundle-uri" skeletonÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 22, 2022
  73. 02/11 t: create test harness for 'bundle-uri' commandÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 22, 2022
  74. 03/11 clone: request the 'bundle-uri' command when availableÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 22, 2022
  75. 05/11 transport: rename got_remote_headsDerrick Stolee via GitGitGadget, Dec 22, 2022
  76. 04/11 bundle-uri client: add boolean transfer.bundleURI settingÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 22, 2022
  77. 07/11 bundle-uri: serve bundle.* keys from configDerrick Stolee via GitGitGadget, Dec 22, 2022
  78. 06/11 bundle-uri client: add helper for testing serverÆvar Arnfjörð Bjarmason via GitGitGadget, Dec 22, 2022
  79. Jeff KingDec 30, 2022
  80. Derrick StoleeJan 5, 2023
  81. test-bundle-uri: drop unused variablesJeff King, Jan 6, 2023
  82. Derrick StoleeJan 6, 2023
  83. 08/11 strbuf: introduce strbuf_strip_file_from_path()Derrick Stolee via GitGitGadget, Dec 22, 2022
  84. 09/11 bundle-uri: allow relative URLs in bundle listsDerrick Stolee via GitGitGadget, Dec 22, 2022
  85. 10/11 bundle-uri: download bundles from an advertised listDerrick Stolee via GitGitGadget, Dec 22, 2022
  86. 11/11 clone: unbundle the advertised bundlesDerrick Stolee via GitGitGadget, Dec 22, 2022
  87. Junio C HamanoDec 25, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.