> Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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.
OK - I'll use that.
> > 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.
I didn't want to unnecessarily exclude features like signed URLs which
may change the way the URL is - for example, in Google Cloud Storage,
the signed part is a suffix [1]. I'll include this in the commit
message.
Having said that, after rereading my patch:
(1) I'm not sure anymore if the restriction is that there must be a
hash in the filename. It might be just that the filename
must end in ".pack.temp". (Having said that, if the filename was
not named "<hash>.pack.temp", it would look different to the rest
of the contents of "objects/pack/", which may or may not be fine.)
(2) The filename restriction in question is on the local filename, not
the URL. We could do any manipulation we want on the URL (e.g. by
appending ".pack.temp").
And one idea that came up at $DAYJOB is that if we're using a suffix of
the URL as the filename, there may be a clash of names anyway, so we
might as well use the hash instead (which is reported by the server).
I'll take a further look - maybe this patch will no longer be needed.
[1] https://cloud.google.com/storage/docs/access-control/signed-urls
