Re: Handling of paths

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 21, 2017, 15:15 UTC
Message-ID: <xmqq1sp9izy2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAG0OSgfWZAbr1_j-SYYZyAzOvW4mrSFa7bBkfhRbJskgdGmsZQ@mail.gmail.com>

Victor Toni <victor.toni@gmail.com> writes:

Show 8 quoted lines

> 2017-07-20 22:30 GMT+02:00 Junio C Hamano <gitster@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.