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
I won't optimize it until I see someone shows me they have a use case
for it.
(*) either that or my coworkers keep pissing me off on purpose when
they never clean trailing spaces.
Nguyễn Thái Ngọc Duy (2):
dir: warn about trailing spaces in exclude pattern
dir: ignore trailing spaces in exclude patterns
Documentation/gitignore.txt | 3 +++
dir.c | 9 +++++++++
2 files changed, 12 insertions(+)
--
1.8.5.2.240.g8478abd
@@ -77,6 +77,9 @@ PATTERN FORMAT Put a backslash ("`\`") in front of the first hash for patterns that begin with a hash.+ - Trailing spaces are ignored unless they are quoted with backlash+ ("`\`").+ - An optional prefix "`!`" which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent
From: Jeff King <hidden> Date: 2016-06-15 22:59:52
On Sat, Feb 08, 2014 at 03:10:02PM +0700, Nguyễn Thái Ngọc Duy wrote:
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.
I guess leading spaces are not as frustrating, but I wonder if it would
be more consistent to say that we soak up all whitespace. That is also a
regression, but I agree that these are exceptional cases, and as long as
we provide an "out" for people to cover them via quoting, ignoring the
whitespace seems like a sane default.
People can still quote trailing spaces, which will not be ignored (and
much more visible). Quoting comes with a cost of doing fnmatch(). But
I won't optimize it until I see someone shows me they have a use case
for it.
I naively expected that:
echo 'trailing\ \ ' >.gitignore
would count as quoting, but your patch doesn't handle that. It _does_
seem to work currently (that is, the backslashes go away and we treat it
literally), but I am not sure if that is planned, or simply happens to
work.
I guess by quoting you meant:
echo '"trailing "' >.gitignore
Anyway, here are some tests I wrote up while playing with this. They do
not pass with your current patch for the reasons above, but maybe they
will be useful to squash in (either after tweaking the tests, or
tweaking the patch).
On Sat, Feb 8, 2014 at 11:45 PM, Jeff King [off-list ref] wrote:
On Sat, Feb 08, 2014 at 03:10:02PM +0700, Nguyễn Thái Ngọc Duy wrote:
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.
I guess leading spaces are not as frustrating, but I wonder if it would
be more consistent to say that we soak up all whitespace. That is also a
regression, but I agree that these are exceptional cases, and as long as
we provide an "out" for people to cover them via quoting, ignoring the
whitespace seems like a sane default.
Hm...
quoted
People can still quote trailing spaces, which will not be ignored (and
much more visible). Quoting comes with a cost of doing fnmatch(). But
I won't optimize it until I see someone shows me they have a use case
for it.
I naively expected that:
echo 'trailing\ \ ' >.gitignore
would count as quoting, but your patch doesn't handle that. It _does_
seem to work currently (that is, the backslashes go away and we treat it
literally), but I am not sure if that is planned, or simply happens to
work.
No that's what I had in mind. But yeah my patches are flawed.
I guess by quoting you meant:
echo '"trailing "' >.gitignore
This makes " special. If we follow shell convention then things
between ".." should be literal (e.g. "*" is no longer a wildcard). We
don't support it yet. So I rather go with backslash as it adds less
code.
quoted hunk
Anyway, here are some tests I wrote up while playing with this. They do
not pass with your current patch for the reasons above, but maybe they
will be useful to squash in (either after tweaking the tests, or
tweaking the patch).
@@ -77,6 +77,9 @@ PATTERN FORMAT Put a backslash ("`\`") in front of the first hash for patterns that begin with a hash.+ - Trailing spaces are ignored unless they are quoted with backlash+ ("`\`").+ - An optional prefix "`!`" which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent
From: Jeff King <hidden> Date: 2016-06-15 22:59:52
On Sun, Feb 09, 2014 at 06:48:18AM +0700, Duy Nguyen wrote:
quoted
I guess by quoting you meant:
echo '"trailing "' >.gitignore
This makes " special. If we follow shell convention then things
between ".." should be literal (e.g. "*" is no longer a wildcard). We
don't support it yet. So I rather go with backslash as it adds less
code.
For some reason I was thinking that we already handled double-quotes
here (as we do in other places where quoting is optional). But it looks
like we don't currently, so yeah, I don't think it is worth adding due
to the potential confusion.
Backslash-escaping was what I had originally assumed you meant, and it
was, so we are all on the same page (the patch was just broken. ;) ).
-Peff