On Fri, Jul 21, 2017 at 08:15:17AM -0700, Junio C Hamano wrote: > In general, I (and other experienced reviewers here) prefer to give > chances to people who are new to the Git development community and > are inclined to do so to scratch their own itch, by giving analysis > of the problem and a suggested route to solve it, but without giving > the final solution in a patch form. After all, many developers > (including me) started from small changes before getting involved > more deeply to the project and starting to play more important > roles. This is a good point, and I should remember to do it more, too. It's often faster to do a small patch yourself than to help walk a first-timer through it, but keeping the community healthy is an important step. At any rate, your patch to use config_pathname() looks like the right thing to me. > Having said all that, I suspect that your original problem > description might point at another thing we may want to look into. > > The patch under discussion may have solved the "~[username]/" prefix > issue, but I offhand am not sure if a path-like variable that holds > a relative path behaves sensibly when they appear in configuration > files and in a file that has configuration snippets that is included > with the "[include] path=..." thing, and if there is a need to clarify > and/or update the rules. The "[include]path" behavior is intentional and documented: it takes the path relative to the including file. I think that would be a reasonable behavior for path-like variables in general (and a path-like variable in an included file would be relative to that included file; this should Just Work because the include mechanism keeps a stack of files). I could probably sketch out a patch, but per the above discussion I'll leave it for now. Also, I'm lazy. ;) -Peff
