On Thu, Nov 08, 2018 at 09:30:15AM +0900, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Wed, Nov 07, 2018 at 10:36:52PM +0100, Johannes Sixt wrote: > > > > All that said, if we're just interested in allowing this for config, > > then we already have such a wrapper function: git_config_pathname(). > > > > So I don't think it's a big deal to implement it in any of these ways. > > It's much more important to get the syntax right, because that's > > user-facing and will be with us forever. > > All of us are on the same page after seeing the clarification by > Dscho, it seems. I came to pretty much the same conclusion this > morning before reading this subthread. Outside config values, the > callers of expand_user_path() only feed "~/.git$constant", and they > are all about "personal customization" that do not want to be shared > with other users of the same installation, so "relative to runtime > prefix" feature would not be wanted. But we do not know about new > caller's needs. For now I am OK to have it in expand_user_path(), > possibly renaming the function if people feel it is needed (I don't). I think we would want to carefully think about the call in enter_repo(). We do not want git-daemon to accidentally expose repositories in $RUNTIME_PREFIX. Looking over the code, I think this is OK. The expansion happens in enter_repo(), and then we take the path that was found and do our ok_paths checks on it (which makes sense -- even now you'd ask to export "/home/" and it would need to look at "~peff/repo.git" and expand that to "/home/peff/repo.git" before doing a simple string check. > Between ~<reserved name> and $VARIABLE_LOOKING_THINGS, I do not have > a strong preference either way, but I am getting an impression that > the latter is more generally favoured in the discussion? I certainly prefer the latter, but I thought I was the only one to have expressed support so far. ;) -Peff
