Hilco Wijbenga writes:
> Naturally, this behaviour makes perfect sense: "/*" means everything.
> Still, I was wondering whether it might be a good idea to make an
> exception for '.gitignore' itself? Then if somebody *really* wanted to
> ignore '.gitignore' they could add "/.gitignore" to '.gitig
On 25 September 2012 16:13, Junio C Hamano wrote:
> Hilco Wijbenga writes:
>
>> Naturally, this behaviour makes perfect sense: "/*" means everything.
>> Still, I was wondering whether it might be a good idea to make an
>> exception for '.gitignore' itself? Then if somebody *really* wanted to
>> i
I want a feature. It may be a bad-idea(tm). Advice appreciated.
I want git to be able to include, in its gitignore files, sub-files of
ignores or have it understand a directory of ignore files. Or both.
The use case for this is where I did not write my own rules, but I want
to keep them updated.
> The use case for this is where I did not write my own rules, but I want
> to keep them updated. https://github.com/github/gitignore is a damn good
> resource, but I want to pull it and include relevant bits project by
> project and/or system wide. I don't want to have to update many projects
> ma
> I'm thinking something like ". path/to/include/file" in an ignore file,
> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore
> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent
> mixture of these things.
I think the rc.d-like approach with directories is
On 27/10/16 15:22, Stefan Beller wrote:
>> The use case for this is where I did not write my own rules, but I want
>> to keep them updated. https://github.com/github/gitignore is a damn good
>> resource, but I want to pull it and include relevant bits project by
>> project and/or system wide. I don
On 27/10/16 21:19, Alexei Lozovsky wrote:
>> I'm thinking something like ". path/to/include/file" in an ignore file,
>> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore
>> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent
>> mixture of these things.
>
> I
On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:
> The use case for this is where I did not write my own rules, but I want
> to keep them updated. https://github.com/github/gitignore is a damn good
> resource, but I want to pull it and include relevant bits project by
> project and/or
uot; or even "add support for
.gitignore.d as well as .gitignore"
One thing to keep in mind would be that we should make sure we can
handle the .gitignore being a submodule or a git repository, so that
users could just do something like
"git submodule add .gitignore and then track git ignore
contents from a repository in a nice way.
By this I mean that the reading of files in .gitignore directory
should exclude reading .git or other hidden files in some documented
manor so as to avoid problems when linking to a git directory for its
contents.
Thanks,
Jake
> -Peff
On 27/10/16 23:50, Jeff King wrote:
> I'd shy away from an actual include directive, as it raises a lot of
> complications:
I'm leaning that way now too.
> - we parse possibly-hostile .gitignore files from cloned repositories.
> What happens when I include ask to include /etc/passwd? Probab
On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
> > - we parse possibly-hostile .gitignore files from cloned repositories.
> > What happens when I include ask to include /etc/passwd? Probably
> > nothing, but there are setups where it might matter (e.g., something
> > li
epository, so that
> users could just do something like
>
> "git submodule add .gitignore and then track git ignore
> contents from a repository in a nice way.
>
> By this I mean that the reading of files in .gitignore directory
> should exclude reading .git or other hidd
On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
> > I think the normal behavior in such "foo.d" directory is to just sort
> > the contents lexically and read them in order, as if they were all
> > concatenated together, and with no recursion. I.e., behave "as if" the
> > user had run
On Thu, Oct 27, 2016 at 04:55:08PM -0400, Jeff King wrote:
> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
>
> > > - we parse possibly-hostile .gitignore files from cloned repositories.
> > > What happens when I include ask to include /etc/passwd? Probably
> > > nothing,
On 28/10/16 10:04, Jeff King wrote:
> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
>
>>> I think the normal behavior in such "foo.d" directory is to just sort
>>> the contents lexically and read them in order, as if they were all
>>> concatenated together, and with no recursion. I
On Thu, Oct 27, 2016 at 2:04 PM, Jeff King wrote:
> I'm not convinced this is needed for in-repo .gitignore files. The point
> is that you are pulling together separate files that may be administered
> independently. But git repositories inherently have a whole-project
> view. I'm not sure that se
On 28/10/16 09:55, Jeff King wrote:
> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
>
>>> - we parse possibly-hostile .gitignore files from cloned repositories.
>>> What happens when I include ask to include /etc/passwd? Probably
>>> nothing, but there are setups where it
On 28/10/16 10:55, Aaron Pelly wrote:
> 2) I fetch a repo with a hostile ignore file. It includes files from
> $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay
> attention. Commit. Push. Problems if my test data comes from production.
>
> Is this mitigated currently?
>
> Not that gi
On 28/10/16 10:07, Jeff King wrote:
> I think it does
> introduce compatibility complications. People with older git will not
> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local
> matter.
I know. I don't think it's a serious compatibility issue, but more
important people may
On 28/10/16 10:07, Jeff King wrote:
> I think it does
> introduce compatibility complications.
If this is not a show stopper, I am happy to knock out a short
functional spec. I'll give it some hours before I begin.
Jeff King writes:
> However, as I said elsewhere, I'm not convinced this feature is all that
> helpful for in-repository .gitignore files, and I think it does
> introduce compatibility complications. People with older git will not
> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely
On Fri, Oct 28, 2016 at 11:17:26AM +1300, Aaron Pelly wrote:
> On 28/10/16 10:55, Aaron Pelly wrote:
> > 2) I fetch a repo with a hostile ignore file. It includes files from
> > $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay
> > attention. Commit. Push. Problems if my test data com
On 28/10/16 15:54, Junio C Hamano wrote:
> Jeff King writes:
>
>> However, as I said elsewhere, I'm not convinced this feature is all that
>> helpful for in-repository .gitignore files, and I think it does
>> introduce compatibility complications. People with older git will not
>> respect your .g
On Fri, Oct 28, 2016 at 4:04 AM, Jeff King wrote:
> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
>
>> > I think the normal behavior in such "foo.d" directory is to just sort
>> > the contents lexically and read them in order, as if they were all
>> > concatenated together, and wit
On Fri, Oct 28, 2016 at 4:32 PM, Aaron Pelly wrote:
> Or how about a new githook that can intelligently create or return the
> details? This would be my least favourite option unless it was
> configured in an obvious place.
I wonder if smudge/clean filters can be used to recreate in-tree
.gitigno
On Fri, Oct 28, 2016 at 10:32:07PM +1300, Aaron Pelly wrote:
> On 28/10/16 15:54, Junio C Hamano wrote:
> > Jeff King writes:
> >
> >> However, as I said elsewhere, I'm not convinced this feature is all that
> >> helpful for in-repository .gitignore files, and I think it does
> >> introduce comp
Hello,
I have just noticed that the documentation for gitignore is missing
documentation on using the ? to match any single character. I have
included a example below with git version 2.14.1.
|11:05:09 j ~/Development/ls-ignore [master] $ git status On branch
master Your branch is up-to-date with
Hi,
I'm trying to make JGit .gitignore parser compatible to Git behavior and need
help to understand some corner cases.
Git seem to fail to match file names if the ignore rule contain a single
bracket '[' and seem to have inconsistent behavior for a single ']'.
For all experiments below I was u
Hi all!
I'm sorry if the letter came twice. I have troubles with my post client.
I want to organize my repository so its submodules would be located at the root
of repository. I'm trying to create .gitignore to ignore all files and don't
ignore directories at the same time:
$ cat .gitignore
*
!*
On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
> Hi,
>
> I've often found the '**' (extended) shell glob useful for matching
> any string crossing directory boundaries: it's especially useful if
> you only have a toplevel .gitignore, as opposed to a per-directory
> .gitignore. Unfortunately,
Stefano Lattarini wrote:
> On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
>> Hi,
>>
>> I've often found the '**' (extended) shell glob useful for matching
>> any string crossing directory boundaries: it's especially useful if
>> you only have a toplevel .gitignore, as opposed to a per-director
On Tue, Oct 2, 2012 at 3:24 PM, Ramkumar Ramachandra wrote:
> Stefano Lattarini wrote:
>> On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
>>> Hi,
>>>
>>> I've often found the '**' (extended) shell glob useful for matching
>>> any string crossing directory boundaries: it's especially useful if
Am 03.10.2012 13:35, schrieb Nguyen Thai Ngoc Duy:
> On Tue, Oct 2, 2012 at 3:24 PM, Ramkumar Ramachandra
> wrote:
>> Stefano Lattarini wrote:
>>> On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
Hi,
I've often found the '**' (extended) shell glob useful for matching
any st
On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann wrote:
> */foo/bar
> */*/foo/bar
> */*/*/foo/bar
>
> Using "**/foo/bar" instead would be a great improvement
If this "**/foo/bar" (i.e. no wildcards except one ** at the
beginning) is popular, we could optimize this case, turning fmatch()
into strncmp(
Am 03.10.2012 15:42, schrieb Nguyen Thai Ngoc Duy:
> On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann wrote:
>> */foo/bar
>> */*/foo/bar
>> */*/*/foo/bar
>>
>> Using "**/foo/bar" instead would be a great improvement
>
> If this "**/foo/bar" (i.e. no wildcards except one ** at the
> beginning) is popu
- Original Message -
From: Nguyen Thai Ngoc Duy
Date: 10/3/2012 7:42 AM
On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann wrote:
*/foo/bar
*/*/foo/bar
*/*/*/foo/bar
Using "**/foo/bar" instead would be a great improvement
If this "**/foo/bar" (i.e. no wildcards except one ** at the
beginnin
On January 29, 2018 6:30 AM, Jack F wrote:
> I have just noticed that the documentation for gitignore is missing
> documentation on using the ? to match any single character. I have included
> a example below with git version 2.14.1.
>
> |11:05:09 j ~/Development/ls-ignore [master] $ git status On
Ah. Yes it does. Apologies. Maybe a "See glob(7) for more pattern
matching options, including ! ? [] *"
Thank you very much.
Cheers.
From,
Jack
On 29/01/18 15:47, Randall S. Becker wrote:
> On January 29, 2018 6:30 AM, Jack F wrote:
>> I have just noticed that the documentation for gitignore is
On Mon, Jan 29, 2018 at 10:47:10AM -0500, Randall S. Becker wrote:
> The implication of support for ? is there through the following paragraph
> from the gitignore documentation:
>
> "Otherwise, Git treats the pattern as a shell glob suitable for
> consumption by fnmatch(3) with the FNM_P
On Tue, Jan 30 2018, Duy Nguyen jotted:
> On Mon, Jan 29, 2018 at 10:47:10AM -0500, Randall S. Becker wrote:
>> The implication of support for ? is there through the following paragraph
>> from the gitignore documentation:
>>
>> "Otherwise, Git treats the pattern as a shell glob suitable for
On Tue, Jan 30, 2018 at 6:07 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Tue, Jan 30 2018, Duy Nguyen jotted:
>
>> On Mon, Jan 29, 2018 at 10:47:10AM -0500, Randall S. Becker wrote:
>>> The implication of support for ? is there through the following paragraph
>>> from the gitignore documentation:
>
Andrey Loskutov writes:
> Next, the surprising table for ']':
> --
> rule | file | match?
> --
> ] ] true
> ]* ] true
> *] ] true
> *] a]true
> --
>
> Here Git does no
On Sunday 27 September 2015 10:58 Andreas Schwab wrote:
>
> ] by itself is not special in a glob.
>
> Andreas.
>
OK, this would explain the current state: once Git sees opened bracket, it
always tries to parse the glob pattern and if this fails (if the bracket is not
closed), the ignore rule
On Sun, Sep 27, 2015 at 5:01 AM, Andrey Loskutov wrote:
> ...
> Anyway, it would be nice to hear what should be the "right" way to interpret
> the tables above.
>
> BTW the only official documentation I found about ignore rules:
>
> https://www.kernel.org/pub/software/scm/git/docs/gitignore.html
Duy Nguyen writes:
> This is already answered. I just want to add that C Git has stopped
> using system fnmatch for some time (part of the reason is system
> fnmatch behaves differently in corner cases). If you don't mind C,
> have a look at dowild() in wildmatch.c, or t/t3070-wildmatch.sh for
>
On Monday 28 September 2015 10:40 Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > This is already answered. I just want to add that C Git has stopped
> > using system fnmatch for some time (part of the reason is system
> > fnmatch behaves differently in corner cases). If you don't mind C,
> > ha
Andrey Loskutov writes:
> On Monday 28 September 2015 10:40 Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > This is already answered. I just want to add that C Git has stopped
>> > using system fnmatch for some time (part of the reason is system
>> > fnmatch behaves differently in corner ca
Hello,
I've found a change in the way .gitignore works, and I'm not sure if
it's a bug
or intended.
Previously, one could use the following .gitignore:
*
!/foo
!/foo/bar.txt
!/baz
!/baz/quux
!/baz/quux/**/*
And these files would be seen by git:
foo/bar.txt
baz/q
On 12.10.2015 13:30, Aleksey Komarov wrote:
> Now, I'm trying to add a submodule to my repository, but fail to understand
> why
> my .gitignore prevents it from being added. I use the following command to
> check
> if my submodule will be ignored or not:
>
> $ git add --dry-run --ignore-missing
2015-10-12 14:30 GMT+08:00 Aleksey Komarov :
> Hi all!
>
> I'm sorry if the letter came twice. I have troubles with my post client.
>
> I want to organize my repository so its submodules would be located at the
> root
> of repository. I'm trying to create .gitignore to ignore all files and don't
>
On 17.10.2015 19:46, Jiang Xin wrote:
> 2015-10-12 14:30 GMT+08:00 Aleksey Komarov :
>> Hi all!
>>
>> I'm sorry if the letter came twice. I have troubles with my post client.
>>
>> I want to organize my repository so its submodules would be located at the
>> root
>> of repository. I'm trying to
To ignore all .js file under a directory `lib', I can use "lib/**/js" to match
them. But when using git command such as "git add", using "git add lib/\*.js"
is sufficient. Why is this difference in glob mode?
I have heard that there are many different glob mode out there (e.g., bash has
many diffe
On Fri, Mar 4, 2016 at 9:11 AM, Charles Strahan wrote:
> Hello,
>
> I've found a change in the way .gitignore works, and I'm not sure if
> it's a bug
> or intended.
Can't look into this just yet. Quick question, what's the git version
you're currently running?
--
Duy
--
To unsubscribe from this
On Thu, Mar 03, 2016 at 09:11:56PM -0500, Charles Strahan wrote:
> Hello,
>
> I've found a change in the way .gitignore works, and I'm not sure if
> it's a bug
> or intended.
>
> Previously, one could use the following .gitignore:
>
> *
> !/foo
> !/foo/bar.txt
> !/baz
> !/baz
I'm on 2.7.0.
Here's a quick sanity check:
├── baz
│ ├── quux
│ │ ├── corge
│ │ │ └── wibble.txt
│ │ └── grault.txt
│ └── waldo.txt
└── foo
├── bar.txt
└── garply.txt
$ git --version
git version 2.7.0
$ git status -sb -uall
## Initial commit on master
?? baz/quux/corge
On Fri, Mar 04, 2016 at 01:12:37AM -0500, Charles Strahan wrote:
> I'm on 2.7.0.
>
> Here's a quick sanity check:
>
> ├── baz
> │ ├── quux
> │ │ ├── corge
> │ │ │ └── wibble.txt
> │ │ └── grault.txt
> │ └── waldo.txt
> └── foo
> ├── bar.txt
> └── garply.txt
>
> $ git --
On Fri, Mar 4, 2016 at 6:56 PM, Kevin Daudt wrote:
> Verified that it's different in 2.7.0, but 2.7.2 gives expected output.
Thanks. 2.7.1 reverts the faulty commit from 2.7.0 that generated two
other regression reports before this one. I guess it's all good then
(except for the people still on 2
Duy Nguyen writes:
> On Fri, Mar 4, 2016 at 6:56 PM, Kevin Daudt wrote:
>> Verified that it's different in 2.7.0, but 2.7.2 gives expected output.
>
> Thanks. 2.7.1 reverts the faulty commit from 2.7.0 that generated two
> other regression reports before this one. I guess it's all good then
> (e
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Fri, Mar 4, 2016 at 6:56 PM, Kevin Daudt wrote:
>>> Verified that it's different in 2.7.0, but 2.7.2 gives expected output.
>>
>> Thanks. 2.7.1 reverts the faulty commit from 2.7.0 that generated two
>> other regression reports before this one
On Sat, Mar 5, 2016 at 12:28 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Fri, Mar 4, 2016 at 6:56 PM, Kevin Daudt wrote:
>>> Verified that it's different in 2.7.0, but 2.7.2 gives expected output.
>>
>> Thanks. 2.7.1 reverts the faulty commit from 2.7.0 that generated two
>> other reg
typo fixes
On Sat, Mar 5, 2016 at 7:43 AM, Duy Nguyen wrote:
> On Sat, Mar 5, 2016 at 12:28 AM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> On Fri, Mar 4, 2016 at 6:56 PM, Kevin Daudt wrote:
Verified that it's different in 2.7.0, but 2.7.2 gives expected output.
>>>
>>> Thanks. 2.7
The fix on my side was quite easy (and my .gitignore is probably a _lot_
hairier
than most), and as Duy suggests, I think the new behavior makes a bit
more
sense. Personally, I would be pleased with keeping the new behavior, and
chalking it up to an unintentional bug fix (the best kind).
Either wa
Charles Strahan writes:
> ...as Duy suggests, I think the new behavior makes a bit
> more sense.
After re-reading your original example, I am inclined to agree with
this.
> Either way, of course, I'd like for it to not change back and
> forth between releases :).
>
> Perhaps just an announcemen
xcluded, the following conditions must be met:
- The directory part in the re-include rules must be literal (i.e. no
wildcards)
+A re-inclusion of a directory makes all files in the directory
+unignored. For example, suppose you have files `.gitignore`,
+`dir/file1`, `dir/file2`, and `dir
gnore`,
> +`dir/file1`, `dir/file2`, and `dir/file3`, and have the following in
> +your `.gitignore`:
> +
> +
> +*
> +!dir
> +# dir/file1 is not mentioned in .gitignore
> +dir/file2
> +!dir/file3
> +
> +
> +Then:
> +
> + - `
On Tue, Mar 8, 2016 at 1:14 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> We need documentation update to settle this one before 2.8 final
>> ships, as we seem to be seeing more and more end-user confusion on
>> the list. I tried to come up with a trimmed-down example, which is
>> show
-148,7 +148,43 @@ excluded, the following conditions must be met:
be in the same .gitignore file.
- The directory part in the re-include rules must be literal (i.e. no
- wildcards)
+ wildcards and has to start with a `/`).
+
+A re-inclusion of a directory makes all files in the directo
On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote:
> So what do we want to do for the upcoming release?
I don't know. Befoire 2.8.0, all three matching cases are broken. With
the current changes on 2.8.0, one case is fixed with the other cases
broken. I guess it can create even more confusion.
Junio C Hamano writes:
> It is between (1) the current code is good enough ...
> or (2) the half-way implementation we
> have does not give enough advancement ... and we
> are better off reverting the whole thing to go back to 2.7.2
> behaviour, planning to do a better job in the next cycle.
>
>
Duy Nguyen writes:
> On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote:
>> So what do we want to do for the upcoming release?
>
> I don't know. Befoire 2.8.0, all three matching cases are broken. With
> the current changes on 2.8.0, one case is fixed with the other cases
> broken. I guess it
e directory
> +unignored. For example, suppose you have files `.gitignore`,
> +`dir/file1`, `dir/file2`, and `dir/file3`, and have the following in
> +your `.gitignore`:
> +
> +
> +# .gitignore is not mentioned in .gitignore
> +*
> +!/dir
> +# dir/file1 is not
Duy Nguyen writes:
> On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote:
>> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
>> index 3ded6fd..91d1ce2 100644
>> --- a/Documentation/gitignore.txt
>> +++ b/Documentation/gitignore.txt
>> @@ -148,7 +148,43 @@ excluded, the fo
On Thu, Mar 10, 2016 at 1:02 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote:
>>> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
>>> index 3ded6fd..91d1ce2 100644
>>> --- a/Documentation/gitignore.txt
>>> +++ b/Docu
Duy Nguyen writes:
> A bit off topic, but these two paragraphs may need rephrasing, I don't
> really understand what it's trying to say
>
> - If the pattern does not contain a slash '/', Git treats it as
>a shell glob pattern and checks for a match against the
>pathname relative to the l
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> A bit off topic, but these two paragraphs may need rephrasing, I don't
>> really understand what it's trying to say
>>
>> - If the pattern does not contain a slash '/', Git treats it as
>>a shell glob pattern and checks for a match against th
On Thu, Mar 10, 2016 at 7:59 AM, Junio C Hamano wrote:
> In any case, back to "on topic" part again; I couldn't come up with
> a better rewrite using named rules (partly because you need to
> clearly define each rule before referring them, and some of the
> rules are temporary workarounds for the
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 spac
I've long been confused by something in the man page for gitignore. I think
it's unclear and I'd like to propose a change. The passage is this (source at
https://git.kernel.org/pub/scm/git/git-manpages.git/tree/man5/gitignore.5):
Two consecutive asterisks ("**") in patterns matched against ful
Hi Yubun,
From: "Yubin Ruan"
To ignore all .js file under a directory `lib', I can use "lib/**/js" to
match
them. But when using git command such as "git add", using "git add
lib/\*.js"
is sufficient. Why is this difference in glob mode?
I have heard that there are many different glob mode out
On Sun, Jun 3, 2018 at 2:58 AM, Yubin Ruan wrote:
> To ignore all .js file under a directory `lib', I can use "lib/**/js" to match
> them. But when using git command such as "git add", using "git add lib/\*.js"
> is sufficient. Why is this difference in glob mode?
Historical reasons mostly. '**'
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitignore.txt| 19 +++
attr.c | 4 +++-
dir.c | 4 +++-
t/t0003-attributes.sh | 38 ++
t/t3001-ls-files-others
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitignore.txt| 19 +++
dir.c | 4 +++-
t/t0003-attributes.sh | 37 +
t/t3001-ls-files-others-exclude.sh | 18 ++
4 files ch
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 w
On Sat, Feb 8, 2014 at 11:45 PM, Jeff King wrote:
> 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. A
This reroll now respects backslash quoting. Thanks Jeff and Torsten
for the comments.
Nguyễn Thái Ngọc Duy (2):
dir: warn about trailing spaces in exclude patterns
dir: ignore trailing spaces in exclude patterns
Documentation/gitignore.txt | 3 +++
dir.c | 20 +
On Sun, Feb 09, 2014 at 06:48:18AM +0700, Duy Nguyen wrote:
> > 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 ye
Nguyễn Thái Ngọc Duy 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
On Mon, Feb 10, 2014 at 11:07 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy 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
ent to "`abc/`" (which is also equivalent
to "`/abc/`").
> +
> + - A slash followed by two consecutive asterisks then a slash
> + matches zero or more directories. For example, "`a/**/b`"
> + matches "`a/b`", "`a/x/b`", "`a/x/y/b
u write either
>
> - A trailing "/**" matches everything inside. For example,
> "/abc/**" is equivalent to "`/abc/`".
>
> or
>
> - A trailing "/**" matches everything inside. For example,
> "abc/**" is equivalent to "
/Documentation/gitattributes.txt
@@ -57,6 +57,12 @@ overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+Note that if a .gitignore rule matches a directory, the directory
+is ignored
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitignore.txt| 19 +++
attr.c | 4 +++-
dir.c | 4 +++-
t/t0003-attributes.sh | 37 +
t/t3001-ls-files-others-
're not in the root, nor do gitignore
files always exist in the root of a git repo. Being able to have
./*.js
in .gitignore would make much sense.
/#!/JoePea
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitignore.txt | 3 +++
attr.c | 4 +++-
dir.c | 5 -
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index c1f692a..eb81d
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Documentation/gitignore.txt| 3 +++
attr.c | 4 +++-
dir.c | 5 -
t/t0003-attributes.sh | 17 +
t/t3001-ls-files-others-exclu
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Documentation/gitignore.txt| 3 +++
attr.c | 4 +++-
dir.c | 5 -
t/t0003-attributes.sh | 17 +
t/t3001-ls-files-others-exclu
On 01.02.2015 14:51, /#!/JoePea wrote:
> I have this in my .gitignore:
>
> ./*.js
>
> I would expect that to cause git to ignore .js files in the same
> folder as .gitignore, but it doesn't do anything. However, this works:
>
> /*.js
>
> I'm not sure what this actually means because a leadi
Stefan Beller writes:
> On 01.02.2015 14:51, /#!/JoePea wrote:
>> I have this in my .gitignore:
>>
>> ./*.js
>>
>> I would expect that to cause git to ignore .js files in the same
>> folder as .gitignore, but it doesn't do anything. However, this works:
>>
>> /*.js
>>
>> I'm not sure what
2015-02-02 11:15 GMT-08:00 Junio C Hamano :
> Stefan Beller writes:
>
>> On 01.02.2015 14:51, /#!/JoePea wrote:
>>> I have this in my .gitignore:
>>>
>>> ./*.js
>>>
>>> I would expect that to cause git to ignore .js files in the same
>>> folder as .gitignore, but it doesn't do anything. However,
1 - 100 of 110 matches
Mail list logo
