SZEDER Gábor writes:
> On Sun, Feb 17, 2019 at 08:49:39AM -0500, Joe Ranieri wrote:
>> "git ls-files -m" can show deleted files, despite -d not having been
>> specified.
>
> To my understanding that's intentional: a deleted file is considered
> modified, because its content clearly doesn't match
On February 18, 2019 10:17, SZEDER Gábor wrote:
> To: Joe Ranieri
> Cc: git@vger.kernel.org
> Subject: Re: [BUG] ls-files showing deleted files (unchecked lstat return
> value)
>
> On Sun, Feb 17, 2019 at 08:49:39AM -0500, Joe Ranieri wrote:
> > "git ls-files -m&quo
On Sun, Feb 17, 2019 at 08:49:39AM -0500, Joe Ranieri wrote:
> "git ls-files -m" can show deleted files, despite -d not having been
> specified.
To my understanding that's intentional: a deleted file is considered
modified, because its content clearly doesn't match the tracked
content.
> This i
On 2/17/19 10:59, Randall S. Becker wrote:
On February 17, 2019 8:50, Joe Ranieri wrote:
"git ls-files -m" can show deleted files, despite -d not having been specified.
This is due to ls-files.c's show_files function calling lstat but not checking
the
return value before calling ie_modified wit
On February 17, 2019 8:50, Joe Ranieri wrote:
> "git ls-files -m" can show deleted files, despite -d not having been
> specified.
> This is due to ls-files.c's show_files function calling lstat but not
> checking the
> return value before calling ie_modified with the uninitialized stat structure.
"git ls-files -m" can show deleted files, despite -d not having been
specified. This is due to ls-files.c's show_files function calling lstat
but not checking the return value before calling ie_modified with the
uninitialized stat structure.
This problem was found using the static analysis too
6 matches
Mail list logo
