Re: [PATCH 0/2] Ignore trailing spaces in .gitignore

Nguyễn Thái Ngọc Duy  [off-list ref] writes:

Trailing spaces are invisible in most standard editors (*). "git diff"
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.

So let's ignore them. Nobody sane would put a trailing space in file
names. But we could be careful and do it in two steps: warn first,
then ignore trailing spaces. Another option is merge two patches in
one and be done with it.

People can still quote trailing spaces, which will not be ignored (and
much more visible). Quoting comes with a cost of doing fnmatch(). But

Hmph, sorry but I fail to see why we need to incur cost for
fnmatch().  We read and parse the file and keep them as internal
strings, so your unquoting (and complaining the unquoted trailng
spaces) can be done at the parse time, while keeping the trailing
spaces the user explicitly told us to keep by quoting in the
internal string that we eventually feed fnmatch() with _after_
unquoting, no?

Puzzled...

On Mon, Feb 10, 2014 at 11:07 AM, Junio C Hamano [off-list ref] wrote:

Nguyễn Thái Ngọc Duy  [off-list ref] writes:

quoted

Trailing spaces are invisible in most standard editors (*). "git diff"
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.

So let's ignore them. Nobody sane would put a trailing space in file
names. But we could be careful and do it in two steps: warn first,
then ignore trailing spaces. Another option is merge two patches in
one and be done with it.

People can still quote trailing spaces, which will not be ignored (and
much more visible). Quoting comes with a cost of doing fnmatch(). But

Hmph, sorry but I fail to see why we need to incur cost for
fnmatch().  We read and parse the file and keep them as internal
strings, so your unquoting (and complaining the unquoted trailng
spaces) can be done at the parse time, while keeping the trailing
spaces the user explicitly told us to keep by quoting in the
internal string that we eventually feed fnmatch() with _after_
unquoting, no?

That's the optimization in the "but" sentence. Another (off topic)
opt. we could do is make "*.[ch]" behave more like "*.c", where we
just try to match the tail part.
-- 
Duy