Re: [PATCH 1/2] Fixes _is_git
- From
Chris Packham <judge.packham@gmail.com>
- Date
- Feb 5, 2015, 08:13 UTC
- Message-ID
- <CAFOYHZAerQWpeOPzD5D3gqKdWYvaCE3vB88Y_iD30eRF5MC2DQ@mail.gmail.com>
- In-Reply-To
- <54D0EEB9.1090803@gmail.com>
On Wed, Feb 4, 2015 at 4:52 AM, Rémi Rampin <remirampin@gmail.com> wrote:
Show 16 quoted lines
> 2015-02-02 12:24 UTC-05:00, Remi Rampin <remirampin@gmail.com>:
>>> proc _is_git {path} {
>>> + if {[file isfile $path]} {
>>> + set fp [open $path r]
>>> + gets $fp line
>>> + close $fp
>>> + if {[regexp "^gitdir: (.+)$" $line line link_target]} {
>
> 2015-02-03 3:44 UTC-05:00, Chris Packham <judge.packham@gmail.com>:
>> It might be simpler to use one of the 'string' commands e.g. string
>> wordend "gitdir: " I also suspect the string functions would be faster
>> than regexp but that probably doesn't matter.
>
> I want to check that the file actually begins with "gitdir: " and then
> extract the path, so I'm not sure if using string functions is that
> simple/fast.Makes sense.
Show 12 quoted lines
> >>> + return [_is_git [file join [file dirname $path] $link_target]] > >> Do we want to avoid pathological cases of infinite recursion? Someone >> would have to maliciously create such a situation. > > Limiting the recursion is very simple, but I'm not sure people are > supposed to stumble on that. More importantly this probably calls for a > different error message, thus a new error result that I am not ready to > implement. But it could be another patch. > But I suppose I can add a simple "return 0" limit to the recursion if > needed, let me know.
It'd have to be fairly intentional to cause any real problems. The one thing I was thinking was to factor out the part that checks for HEAD info objects etc into a __is_git that _is_git could call thus eliminating recursion but I don't see it really being anything more than a theoretical issue.