From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: git@vger.kernel.org, John Cai <johncai86@gmail.com>,
Patrick Steinhardt <ps@pks.im>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2 3/3] upload-pack: allow configuring a missing-action
Date: Wed, 15 May 2024 10:08:58 -0700 [thread overview]
Message-ID: <xmqqv83fvw7p.fsf@gitster.g> (raw)
In-Reply-To: <20240515132543.851987-4-christian.couder@gmail.com> (Christian Couder's message of "Wed, 15 May 2024 15:25:43 +0200")
Christian Couder <christian.couder@gmail.com> writes:
> From: Christian Couder <chriscool@tuxfamily.org>
>
> In case some objects are missing from a server, it might still be
> useful to be able to fetch or clone from it if the client already has
> the missing objects or can get them in some way.
Be more assertive. We do not want to add a new feature randomly
only because it _might_ be useful to somebody in a strange and
narrow use case that _might_ exist.
> For example, in case both the server and the client are using a
> separate promisor remote that contain some objects, it can be better
> if the server doesn't try to send such objects back to the client, but
> instead let the client get those objects separately from the promisor
> remote. (The client needs to have the separate promisor remote
> configured, for that to work.)
Is it "it can be better", or is it "it is always better"? Pick an
example that you can say the latter to make your example more
convincing.
Repository S borrows from its "promisor" X, and repository C which
initially cloned from S borrows from its "promisor" S. Even if C
wants an object in order to fill in the gap in its object graph, S
may not have it (and S itself may have no need for that object), and
in such a case, bypassing S and let C go directly to X would make
sense.
> Another example could be a server where some objects have been
> corrupted or deleted. It could still be useful for clients who could
> get those objects from another source, like perhaps a different
> client, to be able to fetch or clone from the server.
>
> To configure what a server should do if there are such missing
> objects, let's teach `git upload-pack` a new
> `uploadpack.missingAction` configuration variable.
>
> This new missing-action works in a similar way as what `git rev-list`
> and `git pack-objects` already support with their
> `--missing=<missing-action>` command line options. In fact when
> `uploadpack.missingAction` is set to something different than "error",
> `git upload-pack` will just pass the corresponding
> `--missing=<missing-action>` to `git pack-objects`.
>
> So this new missing-action has the same limitations as
> `git pack-objects --missing=<missing-action>`. Especially when not
> using promisor remotes, 'allow-any' works only for blobs.
>
> Another limitation comes from `git upload-pack` itself which requires
> setting `GIT_NO_LAZY_FETCH` to 0 since 7b70e9efb1 (upload-pack:
> disable lazy-fetching by default, 2024-04-16) for lazy fetching from
> a promisor remote to work on the server side.
I am puzzled by this new option.
It feels utterly irresponsible to give an option to set up a server
that essentially declares: I'll serve objects you ask me as best
efforts basis, the pack stream I'll give you may not have all
objects you asked for and missing some objects, and when I do so, I
am not telling you which objects I omitted.
How do you ensure that a response with an incomplete pack data would
not corrupt the repository when the sending side configures
upload-pack with this option? How does the receiving end know which
objects it needs to ask from elsewhere?
Or is the data integrity of the receiving repository is the
responsibility of the receiving user that talks with such a server?
If that is the case, I am not sure if I want to touch such a feature
even with 10ft pole.
Is there anything the sender can do but does not do to help the
receiver locate where to fetch these missing objects to fill the
"unfilled promises"?
For example, the sending side _could_ say that "Sorry, I do not have
all objects that you asked me to---but you could try these other
repositories".
next prev parent reply other threads:[~2024-05-15 17:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 13:51 [PATCH 0/3] Implement filtering repacks Christian Couder
2022-10-12 13:51 ` [PATCH 1/3] pack-objects: allow --filter without --stdout Christian Couder
2022-10-12 13:51 ` [PATCH 2/3] repack: add --filter=<filter-spec> option Christian Couder
2022-10-12 13:51 ` [PATCH 3/3] repack: introduce --force to force filtering Christian Couder
2022-10-14 16:46 ` [PATCH 0/3] Implement filtering repacks Junio C Hamano
2022-10-20 11:23 ` Christian Couder
2022-10-28 19:49 ` Taylor Blau
2022-10-28 20:26 ` Junio C Hamano
2022-11-07 9:12 ` Christian Couder
2022-11-07 9:00 ` Christian Couder
2022-10-25 12:28 ` [PATCH v2 0/2] " Christian Couder
2022-10-25 12:28 ` [PATCH v2 1/2] pack-objects: allow --filter without --stdout Christian Couder
2022-10-25 12:28 ` [PATCH v2 2/2] repack: add --filter=<filter-spec> option Christian Couder
2022-10-28 19:54 ` [PATCH v2 0/2] Implement filtering repacks Taylor Blau
2022-11-07 9:29 ` Christian Couder
2022-11-22 17:51 ` [PATCH v3 " Christian Couder
2022-11-22 17:51 ` [PATCH v3 1/2] pack-objects: allow --filter without --stdout Christian Couder
2022-11-22 17:51 ` [PATCH v3 2/2] repack: add --filter=<filter-spec> option Christian Couder
2022-11-23 0:31 ` [PATCH v3 0/2] Implement filtering repacks Junio C Hamano
2022-12-21 3:53 ` Christian Couder
2022-11-23 0:35 ` Junio C Hamano
2022-12-21 4:04 ` [PATCH v4 0/3] " Christian Couder
2022-12-21 4:04 ` [PATCH v4 1/3] pack-objects: allow --filter without --stdout Christian Couder
2023-01-04 14:56 ` Patrick Steinhardt
2022-12-21 4:04 ` [PATCH v4 2/3] repack: add --filter=<filter-spec> option Christian Couder
2023-01-04 14:56 ` Patrick Steinhardt
2023-01-05 1:39 ` Junio C Hamano
2022-12-21 4:04 ` [PATCH v4 3/3] gc: add gc.repackFilter config option Christian Couder
2023-01-04 14:57 ` Patrick Steinhardt
2024-05-15 13:25 ` [PATCH v2 0/3] upload-pack: support a missing-action Christian Couder
2024-05-15 13:25 ` [PATCH v2 1/3] rev-list: refactor --missing=<missing-action> Christian Couder
2024-05-15 16:16 ` Junio C Hamano
2024-05-15 13:25 ` [PATCH v2 2/3] pack-objects: use the missing action API Christian Couder
2024-05-15 16:46 ` Junio C Hamano
2024-05-24 16:40 ` Christian Couder
2024-05-15 13:25 ` [PATCH v2 3/3] upload-pack: allow configuring a missing-action Christian Couder
2024-05-15 17:08 ` Junio C Hamano [this message]
2024-05-24 16:41 ` Christian Couder
2024-05-24 21:51 ` Junio C Hamano
2024-05-28 10:10 ` Christian Couder
2024-05-28 15:54 ` Junio C Hamano
2024-05-31 20:43 ` Christian Couder
2024-06-01 9:43 ` Junio C Hamano
2024-06-03 15:01 ` Christian Couder
2024-06-03 17:29 ` Junio C Hamano
2024-05-15 13:59 ` [PATCH v2 0/3] upload-pack: support " Christian Couder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqv83fvw7p.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=johncai86@gmail.com \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).