Jeff King <peff@xxxxxxxx> writes: >> > > "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 >> >> Thanks; this is Junio's description from when he picked up the topic >> back in WC #08 from October. I'll need to update before graduating it >> down. > > Yeah, I think you can probably just remove everything from "and also > forces..." on. Hmph, --not --all is a way to make the rev-list error out if the proposed new tips are not connected with existing objects to the "existing" refs, and I thought that removing "hidden" ones from "--all" means that the pusher is now forced to push objects all needed. But you are right. Excluding the hidden refs from "--all" while doing the "rev-list new-tip --not --all" traversal does not exclude pre-existing objects that are only reachable from these hidden refs in the object store, so it does not help ensure that the pusher has to prove they have these objects.
