Victor Toni <victor.t...@gmail.com> writes:
> 2017-07-20 22:30 GMT+02:00 Junio C Hamano <gits...@pobox.com>:
>>
>> I've read the function again and I think the attached patch covers
>> everything that ought to be a filename.
>>
> Your swift reaction is very much appreciated.
> With the background you gave I just started to to create a patch
> myself just to see that you already finished the patch.
Heh, I guess I could have waited to save time ;-)
I did the patch myself in order to avoid wasting your effort to find
and report the issue and time and distraction cost from Charles to
remember what happened 2 years ago and reply to me, because I will
certainly forget if I didn't have some patch readily usable in the
list archive.
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.
Some reviewers are much better than myself in judging if a new
person wants satisfaction of solving himself or herself[*1*], and
they end their analysis and suggestion with a phrase like "Want to
try doing a patch yourself?" I try to follow their example myself,
but I do not always succeed, and this is one of such cases. I guess
you could have immediately responded "OK, let me try to see if I can
fix it myself" before starting to actually work on it ;-)
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.
In any case, thanks for reporting the bugs on two variables, and
welcome to the Git development community.
[Footnote]
*1* Some people just want to report an issue and move on, which is
understandable.
