"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > In Git for Windows, we ran with a patch "in production" for quite a while > where paths starting with a slash (i.e. looking like Unix paths, not like > Windows paths) were interpreted as being relative to the runtime prefix, > when expanded via expand_user_path(). > > This was sent to the Git mailing list as a discussion starter, and it was > pointed out that this is neither portable nor unambiguous. > > After the dust settled, I thought about the presented ideas for a while > (quite a while...), and ended up with the following: any path starting with > <RUNTIME-PREFIX>/ is expanded. This is ambiguous because it could be a valid > path. But then, it is unlikely, and if someone really wants to specify such > a path, it is easy to slap a ./ in front and they're done. I just went back to briefly scan the discussion in late 2018. I think the rough consensus back then was that * It indeed is a problem that there is no syntax for users of "relocatable Git" to use to point at things that come as part of the "relocatable Git" package. * A change to expand_user_path() would be too broad, it makes sense for this feature to be in git_config_pathname(); * We need to get the syntax right. As to the last item, there were a handful of choices raised: - Use "~~"--the downside is that this is not extensible. Use "~runtime-prefix/" would be a better choice (the likelyhood of <RUNTIME-PREFIX>, $RUNTIME_PREFIX, and any other random choice happens to be used as a valid directory name is just as slim as the likelyhood of "runtime-prefix" used as a valid username). - "$RUNTIME_PREFIX" to make it read like a variable---the downside was that it looked TOO MUCH like a variable and risked user confusion (e.g. it may be upsetting that "$HOME/.gitconfig" is not expanded like "~/.gitconfig" is). - %(RUNTIME-PREFIX) to make it similar to how Git replaces various tokens that are understood only in the context of Git. - <RUNTIME-PREFIX>---the downside is that this is an unnecessary new syntax we do not have to introduce. If <RUNTIME-PREFIX> is unlikely to be used as a valid directory name, %(RUNTIME-PREFIX) is just as unlikely. There might have been other ideas floated back then. I have to say that the one you chose in this round is the least favourite of mine, and if you consulted me privately before redoing this round, I would probably have said %(RUNTIME_PREFIX) would make the most sense among the candidates. Thanks.
