Christian Couder <christian.couder@xxxxxxxxx> 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.
