From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: ps/receive-use-only-advertised
Date: Tue, 15 Nov 2022 07:28:43 +0100 [thread overview]
Message-ID: <Y3MxmzestKm9iMTU@ncase> (raw)
In-Reply-To: <Y3Mag8qG2D3qjlmg@nand.local>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
On Mon, Nov 14, 2022 at 11:50:11PM -0500, Taylor Blau wrote:
[snip]
> * ps/receive-use-only-advertised (2022-11-11) 7 commits
> - receive-pack: only use visible refs for connectivity check
> - rev-parse: add `--exclude-hidden=` option
> - revision: add new parameter to exclude hidden refs
> - revision: introduce struct to handle exclusions
> - revision: move together exclusion-related functions
> - refs: get rid of global list of hidden refs
> - refs: fix memory leak when parsing hideRefs config
>
> "git receive-pack" used to use all the local refs as the boundary
> for checking connectivity of the data "git push" sent, but now it
> uses only the refs that it advertised to the pusher. In a
> repository with the .hideRefs configuration, this reduces the
> resource needed to perform the check, and also forces the pusher to
> prove they have all objects that are necessary to complete the
> history on top of only the history available to them.
We have at a later point established that this is not true: the pusher
does not have to prove they have all objects. As the `--not --all` part
in git-rev-list(1) is merely an optimization the semantics aren't
changed at all
> Expecting a (final?) reroll.
I think this is stale, right? There was no further feedback until now,
and in your [1] you say that things look good to you, but that you
intend to wait a few days for further feedback.
Thanks!
Patrick
[1]: <Y27KL0Yg7nzdQ+HC@nand.local>
> cf. <221028.86bkpw805n.gmgdl@evledraar.gmail.com>
> cf. <xmqqr0yrizqm.fsf@gitster.g>
> source: <cover.1668149149.git.ps@pks.im>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-11-15 6:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 4:50 What's cooking in git.git (Nov 2022, #03; Mon, 14) Taylor Blau
2022-11-15 4:59 ` Eric Sunshine
2022-11-15 5:01 ` Taylor Blau
2022-11-15 6:28 ` Patrick Steinhardt [this message]
2022-11-15 6:47 ` ps/receive-use-only-advertised Taylor Blau
2022-11-15 17:28 ` ps/receive-use-only-advertised Jeff King
2022-11-16 2:02 ` ps/receive-use-only-advertised Taylor Blau
2022-11-18 23:27 ` ps/receive-use-only-advertised Junio C Hamano
2022-11-15 8:06 ` rp/maintenance-qol with 'make DEVELOPER=1' (was: What's cooking in git.git (Nov 2022, #03; Mon, 14)) Ævar Arnfjörð Bjarmason
2022-11-15 14:04 ` ms/sendemail-validate-headers, was Re: What's cooking in git.git (Nov 2022, #03; Mon, 14) Johannes Schindelin
2022-11-16 1:20 ` Taylor Blau
2022-11-16 11:48 ` Strawbridge, Michael
2022-11-18 13:24 ` Johannes Schindelin
2022-11-15 20:58 ` Eric Sunshine
2022-11-16 2:04 ` Taylor Blau
2022-11-16 6:07 ` Elijah Newren
2022-11-16 20:16 ` Taylor Blau
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=Y3MxmzestKm9iMTU@ncase \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.