Re: [PATCH 1/8] http: use --stdin when getting dumb HTTP pack

From: Junio C Hamano <gitster@pobox.com>
Date: May 29, 2020, 23:00 UTC
Message-ID: <xmqqmu5qxs6e.fsf@gitster.c.googlers.com>
In-Reply-To: <4d17d560b87746acfd62ff785cc22c09600d4e65.1590789428.git.jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

> When Git fetches a pack using dumb HTTP, it reuses the server's name for
> the packfile (which incorporates a hash), which is different from the
> behavior of fetch-pack and receive-pack.

My first two reads of the above mistakenly thought that for some reason the packfile has the URL to the server encoded in its name, but that is not what you meant by "the server's name". You rather meant "the name the server stores the packfile under", "the name the server gave the packfile", "it reuses the name the server uses for the packfile". The last rephrase may be the easiest to understand.

> A subsequent patch will allow downloading packs over HTTP(S) as part of
> a fetch. These downloads will not necessarily be from a Git repository,
> and thus may not have a hash as part of its name.

A location that is not necessarily a Git repository can still honor the naming convention, so I find this a bit weak argument. After all, the procedure to prepare such a CDN backed file would be using Git and the (git) "natural" name for the resulting packfile is easily available to it, isn't it?

I am not necessarily against loosening the limitation of the shape of the filename, but we may want to say the reason why we want to name the packfile on the CDN side differently from how Git would naturally name them. What benefit would we get out from geing able to do so? Perhaps it makes arrangements such as "you can fetch 'pack-v1.0.pack' to become reasonably up-to-date if you at least have the version v1.0 software", "if the last time you fetched from us was 2020-05-20 or after, you can fetch 'pack-2020-05-20.pack' and be assured that you aren't missing anything", etc.? Such a "why would somebody want to name the packfile differently" would make a more convincing justification.

> Thus, teach http to pass --stdin to index-pack, so that we have no
> reliance on the server's name for the packfile.

OK. By definition, if we feed the packdata via --stdin, the index-pack command would not even _know_ what the filename we use, or the name the other side had. Makes sense.