Re: [PATCH v3] promisor-remote: fix segfault when remote URL is missing

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> writes:

>> is relative to the current working directory, and because the server
>> and these clients must refer to the same repository using this
>> mechanism, this in turn means that the server and all the clients
>> share the same current working directory?
>
> Maybe they don't share the same directory but there is a symlink
> to or a mount of the remote directory.  I agree it's a rare case,
> but the case with no URL is a rare case too.

The meaning of the two instances of the word "rare" is different in
the above sentence, no?

The first one, the setting somebody could use if they really wanted
to is "if you re really pressed to choose between possible and
impossible, you cannot say it is impossible".

It is dubious how such a set-up is useful.  The server is telling
that the other side should now use this new thing (perhaps locally
reachable) so that "a symlink to or a mount of" must be prepared
beforehand in order to use the "the user is told ../foo as a new
lop, and at ../foo there is already usable (remote) object store
available over the network filesystem".  Wouldn't such a $CORP
sysadmin who can prepare "../foo" on the client machines for their
client repositories be able to instead prepare ".git/config" for
them with the same labor?  IOW, the "is dubious how such a set up is
useful" I said is not questioning if it works.  It questions if that
is the way how people _want_ their system to work.

The latter "rare" is "when there is no URL (i.e. r->name fallback
needs to be taken), it would be much more common that the command
'git fetch ../foo main' was given without configuring ../foo remote
(hence URL is missing, but so is fetch refspec), than somebody added
remote."../foo".fetch refspec but choose not to add URL".  There is
absolutely no reason a user would deliberately do so, unless the
only thing they are interested in saying is "hey this works because
of r->name fallback", without considering how much time of others
(e.g. who read their config when they have problem with Git to help
diagnose the problem for them, and then notice and wonder why .URL
is missing there) doing so would waste.

So whichever "rare" we are talking about, ...

>> It may be possible, but would that make _any_ practical sense?  I
>> doubt it.  I would understand perfectly well that the local single
>> machine situation as a good justification to use file:// URL in such
>> a setting, but not for the r->name fallback.

... this point still stands.