Re: Expanding Includes in .gitignore

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 matte

Re: Expanding Includes in .gitignore

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

Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 3:50 AM, Jeff King <p...@peff.net> wrote: > 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

Re: Expanding Includes in .gitignore

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

Re: Expanding Includes in .gitignore

which I >> haven't thought about yet, but probably makes it too hard for the >> limited value it brings. > > Now, if we consider the case of multiple .gitignore files, it > could be unexpected and possibly annoying for negative patterns > in one file to affect the patterns

Re: Expanding Includes in .gitignore

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 >> proje

Re: Expanding Includes in .gitignore

recedence only matters for negative patterns (the ones that start with an exclamation mark, !). For example, suppose you have files 'foo1' and 'foo2'. This .gitignore foo* !foo1 will ignore foo2, but will show foo1. However, if the lines are swapped: !foo1 foo* then both foo1 an

Re: Expanding Includes in .gitignore

> 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 m

Expanding Includes in .gitignore

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

Re: [PATCH] gitignore: ignore output files of coccicheck make target

Am 27.09.2016 um 21:52 schrieb Jakub Narębski: > W dniu 27.09.2016 o 21:01, René Scharfe pisze: >> Signed-off-by: Rene Scharfe <l@web.de> >> --- >> .gitignore | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/.gitignore

Re: [PATCH] gitignore: ignore output files of coccicheck make target

W dniu 27.09.2016 o 21:01, René Scharfe pisze: > Signed-off-by: Rene Scharfe <l@web.de> > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 05cb58a..f370ba0 100644 > --- a/.gitignore > +++ b/.gitigno

[PATCH] gitignore: ignore output files of coccicheck make target

Signed-off-by: Rene Scharfe <l@web.de> --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 05cb58a..f370ba0 100644 --- a/.gitignore +++ b/.gitignore @@ -207,6 +207,7 @@ /tags /TAGS /cscope* +/contrib/coccinelle/*.patch* *.obj *.lib

Re: .gitignore does not ignore Makefile

W dniu 22.09.2016 o 20:26, Junio C Hamano napisał: > Kevin Daudt writes: > >> Often people advise tricks like `git update-index --assume-unchanges >> `, but this does not work as expected. It's merely a promise to >> git that this file does not change (and hence, git will not

Re: .gitignore does not ignore Makefile

Timur Tabi <ti...@codeaurora.org> writes: > So .gitignore only ignores new files, not modified ones? It is determines if an untracked file should be considered by "git add" to add it or ignore it.

Re: .gitignore does not ignore Makefile

change the user had despite the promise to Git. The "abort saying that the file has changed" is merely various codepaths in the current implementation trying to be extra nice. So .gitignore only ignores new files, not modified ones? That seems odd, but I guess that's the way it's a

Re: .gitignore does not ignore Makefile

Kevin Daudt writes: > Often people advise tricks like `git update-index --assume-unchanges > `, but this does not work as expected. It's merely a promise to > git that this file does not change (and hence, git will not check if > this file has changed when doing git status), but

Re: .gitignore does not ignore Makefile

On Thu, Sep 22, 2016 at 09:19:22AM -0500, Timur Tabi wrote: > I have the following .gitignore file in patch arm/arm64/boot/dts: > > *.dtb > qcom > qcom.orig > > When I do a git status, I see this: > > modified: .gitignore > modified: qcom/Makefile >

.gitignore does not ignore Makefile

I have the following .gitignore file in patch arm/arm64/boot/dts: *.dtb qcom qcom.orig When I do a git status, I see this: modified: .gitignore modified: qcom/Makefile All of the other files in arm/arm64/boot/dts/qcom are being ignored, as request. However, the file "Mak

Re: git submodule add spits unrelated to actual problem error msg about .gitignore

t;# no need for a if, but this single line will do: >test -z "$force" && git add --dry-run git.o >/dev/null || exit 1 FWIW Imho exposing error is good but not sufficient alone, since custom gitignore message would still be confusing. -- Sent from a phone which beats iPhone.

Re: git submodule add spits unrelated to actual problem error msg about .gitignore

On Wed, Sep 14, 2016 at 7:03 AM, Yaroslav Halchenko <y...@onerussian.com> wrote: > I have spent some time chasing the wild goose (well - the .gitignore > file) after getting: > > $> git-submodule add --name fcx-1 ./fcx-1/ ./fcx-1/ > The following path is ignored b

git submodule add spits unrelated to actual problem error msg about .gitignore

I have spent some time chasing the wild goose (well - the .gitignore file) after getting: $> git-submodule add --name fcx-1 ./fcx-1/ ./fcx-1/ The following path is ignored by one of your .gitignore files: fcx-1 Use -f if you really want to add it. long story short -- the culp

Re: Bug Report: Too many untracked files (gitignore)

The patterns in question do contain a slash, although they don't start with a slash. I tried changing it to "!/.vim/colors/*" as you recommended, with no change in behavior. I even tried adding a leading slash to every pattern in gitignore, with no effect. Removing the line with &quo

Re: Bug Report: Too many untracked files (gitignore)

On Fri, Sep 2, 2016 at 4:06 PM, Brian Levinstein <blevinst...@gmail.com> wrote: > The relevant repo is here: > https://github.com/blevinstein/dotfiles > > My gitignore file looks like this: > https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e840234

Bug Report: Too many untracked files (gitignore)

The relevant repo is here: https://github.com/blevinstein/dotfiles My gitignore file looks like this: https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore It basically ignores all files, except for specifically whitelisted files. However, when I run

Re: [PATCH] Adds *~ to the .gitignore

Jeff King writes: > On Thu, Jun 09, 2016 at 03:48:12PM -0700, Junio C Hamano wrote: > >> As I said, however, I could support a move to add some selected >> small number of common file extensions, as long as we have some >> (social) mechanism to avoid churning this file every time

Re: [PATCH] Adds *~ to the .gitignore

On Thu, Jun 09, 2016 at 03:48:12PM -0700, Junio C Hamano wrote: > As I said, however, I could support a move to add some selected > small number of common file extensions, as long as we have some > (social) mechanism to avoid churning this file every time somebody > new comes and complains their

Re: [PATCH] Adds *~ to the .gitignore

f the changed data >> > >> > Signed-off-by: Lars Vogel <lars.vo...@vogella.com> >> > --- >> >> We deliberately left this out and kept it out of .gitignore for the >> past 10 years. The justification was that use of Emacs is merely a >>

Re: [PATCH] Adds *~ to the .gitignore

: Lars Vogel <lars.vo...@vogella.com> > > --- > > We deliberately left this out and kept it out of .gitignore for the > past 10 years. The justification was that use of Emacs is merely a > personal choice that is better served by .git/info/excludes; we do > not add .swp for vim users,

Re: [PATCH] Adds *~ to the .gitignore

Lars Vogel <lars.vo...@gmail.com> writes: > This helps contributors (like me) using editors which automatically create ~ > copies of the changed data > > Signed-off-by: Lars Vogel <lars.vo...@vogella.com> > --- We deliberately left this out and kept it out of .giti

[PATCH] Adds *~ to the .gitignore

This helps contributors (like me) using editors which automatically create ~ copies of the changed data Signed-off-by: Lars Vogel <lars.vo...@vogella.com> --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 05cb58a..13c7403 100644 --- a/.git

RE: 2.8.0 gitignore enhancement not working as expected

Hi Duy, I tried your exact example and it worked correctly. But then I tried adding some more files/dirs at the top level and I still see an issue: cat .gitignore /* !a/b/c find * -type f 1 2 3 a/1 a/b/1 a/b/c/1 d/1 git ls-files -o --exclude-standard .gitignore 2 3 a/b/c/1 d/1 Trace output

Re: 2.8.0 gitignore enhancement not working as expected

On Fri, Mar 18, 2016 at 9:32 PM, Richard Furness -X (rfurness - ENSOFT LIMITED at Cisco) wrote: > Hi Duy, > > I tried your exact example and it worked correctly. But then I tried adding > some more files/dirs at the top level and I still see an issue: Thank you. Phew.. I bet

Re: 2.8.0 gitignore enhancement not working as expected

prove the ignore mechanism that lets you say "this >is excluded" and then later say "oh, no, this part (that is a >subset of the previous part) is not excluded". This has still a >known limitation, though." > > Currently, in order to includ

2.8.0 gitignore enhancement not working as expected

of the previous part) is not excluded". This has still a known limitation, though." Currently, in order to include ONLY the files under a/b/c I have the following in .gitignore: /* - Ignore everything !/a - Except directory "a" /a/*- Ignore all sub-dire

RE: 2.8.0 gitignore enhancement not working as expected

ger.kernel.org > Subject: Re: 2.8.0 gitignore enhancement not working as expected > > On Fri, Mar 18, 2016 at 9:32 PM, Richard Furness -X (rfurness - ENSOFT > LIMITED at Cisco) <rfurn...@cisco.com> wrote: > > Hi Duy, > > > > I tried your exact example and it work

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

h '/', Git treats it as >>a shell glob pattern and checks for a match against the >> pathname relative to the location of the `.gitignore` file >>(relative to the toplevel of the work tree if not from a >>`.gitignore` file). >> >> Not sure why &q

Re: Change in .gitignore handling: intended or bug?

s for a match against the >pathname relative to the location of the `.gitignore` file >(relative to the toplevel of the work tree if not from a >`.gitignore` file). > > Not sure why "relative to the location of .gitignore file" matters. We > basically just take `basename

Re: Change in .gitignore handling: intended or bug?

itignore.txt >>> index 3ded6fd..91d1ce2 100644 >>> --- a/Documentation/gitignore.txt >>> +++ b/Documentation/gitignore.txt >>> @@ -148,7 +148,43 @@ excluded, the following conditions must be met: >>> be in the same .gitignore file. >>>

Re: Change in .gitignore handling: intended or bug?

;> +++ b/Documentation/gitignore.txt >> @@ -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

Re: Change in .gitignore handling: intended or bug?

cluded, 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 `/`). Technically '/' can just appear anywhere in the pat

Re: Change in .gitignore handling: intended or bug?

ntation users can work around the implementation deficiency and get a benaviour that is closer than 2.7.2, or (2) the half-way implementation we have does not give enough advancement toward the final goal (i.e. the !dir re-inclusion behaves consistently with the dir that ignores the whole thing underneath, whi

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

) >>> !dir/file3 entry makes difference. >>> >>> Where did my example go wrong? >>> >>> FYI, if I prefix '/' to all the .gitignore entries in the example, i.e. >>> making it >>> >>> * >>> !/dir >>>

Re: Change in .gitignore handling: intended or bug?

t;> the list. I tried to come up with a trimmed-down example, which is >> shown below, but I suspect that the code is not exactly working the >> way it is described in that (1) dir/file1 is ignored and (3) >> !dir/file3 entry makes difference. >> >> Where did my example

Re: Change in .gitignore handling: intended or bug?

pect that the code is not exactly working the > way it is described in that (1) dir/file1 is ignored and (3) > !dir/file3 entry makes difference. > > Where did my example go wrong? > > FYI, if I prefix '/' to all the .gitignore entries in the example, i.e. > making it > >

Re: Change in .gitignore handling: intended or bug?

n example, which is shown below, but I suspect that the code is not exactly working the way it is described in that (1) dir/file1 is ignored and (3) !dir/file3 entry makes difference. Where did my example go wrong? FYI, if I prefix '/' to all the .gitignore entries in the example, i.e. making it

Re: Change in .gitignore handling: intended or bug?

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 :). > >

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

rgue is the correct thing because > you ask to re-include the whole directory "baz". It should behave this > way because exclude rules without '!' behave this way. > > Because positive any negative rules can be nested, by adding a rule to s/any/and/ > reinclude what's insid

Re: Change in .gitignore handling: intended or bug?

!/baz /baz/* !/baz/quux !/baz/quux/**/* you'll get baz/waldo.txt excluded. Yes it's a behavior change. I think the old behavior is unintended. But it's probably out there long enough that many .gitignore files may rely on it and by making it right, I break them. Whether to reve

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

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

Re: Change in .gitignore handling: intended or bug?

y (such as myself), this will set up an identical tree: > > mkdir -p foo > mkdir -p baz/quux/corge > touch foo/bar.txt > touch foo/garply.txt > touch baz/waldo.txt > touch baz/quux/grault.txt > touch baz/quux/corge/wibble.txt > cat <<"EOF" > .git

Re: Change in .gitignore handling: intended or bug?

/wibble.txt cat <<"EOF" > .gitignore * !/foo !/foo/bar.txt !/baz !/baz/quux !/baz/quux/**/* EOF I just checked https://git-scm.com/docs/gitignore and the example at the bottom suggests that this behavior may be expected: $ cat .gitignore # exclude everything excep

Re: Change in .gitignore handling: intended or bug?

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 &

Re: Change in .gitignore handling: intended or bug?

On Fri, Mar 4, 2016 at 9:11 AM, Charles Strahan <char...@cstrahan.com> 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 curre

Change in .gitignore handling: intended or bug?

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

git-mv ignores gitignore file

gitignore(5) manual says that > A gitignore file specifies intentionally untracked files that Git > should ignore. Files already tracked by Git are not affected ... > The purpose of gitignore files is to ensure that certain files not > tracked by Git remain untracked.

Re: [PATCH 0/4] .gitignore, reinclude rules, take 2

Nguyễn Thái Ngọc Duy writes: > Take one was bad and reverted in commit 8c72236. Take two provides a > more complete solution to the pair of rules > > exclude/this > !exclude/this/except/this > > 3/4 should do a better job at stopping regressions in take 1. 4/4 > provides

[PATCH 0/4] .gitignore, reinclude rules, take 2

Take one was bad and reverted in commit 8c72236. Take two provides a more complete solution to the pair of rules exclude/this !exclude/this/except/this 3/4 should do a better job at stopping regressions in take 1. 4/4 provides the solution. I think I have tested (and wrote tests) for all the

Gitignore file exceptions are not applied to untarcked files

interested in /tracked_dir/.../config files. My .gitignore is as follows: # Ignore everything first * # Do not ignore tracked files !/tracked_dir/*/config # Don't ignore .gitignore !.gitignore This works fine until a new directory with a config file is created inside /tracked_dir: /tracked_dir

Re: Gitignore file exceptions are not applied to untarcked files

t too ancient version, so I am not sure how it behaved back then. > I'm only interested in /tracked_dir/.../config files. My .gitignore is as > follows: > > # Ignore everything first > * > # Do not ignore tracked files > !/tracked_dir/*/config > # Don't ignore .gitignore

Re: Gitignore file exceptions are not applied to untarcked files

/F/c mkdir -p D E/F touch a b c D/a D/b D/c E/F/a E/F/b E/F/c echo && echo '.gitignore' && echo '--' echo '*\n!b\n!D/b\n!/D/b\n!/E/*/b' > .gitignore cat .gitignore echo && echo 'With `--ignored`' && echo '--' git status --ignored echo &a

Re: Git 2.7.0 gitignore behaviour regression

On Tue, Jan 5, 2016 at 10:06 PM, Jeff King <p...@peff.net> wrote: > On Tue, Jan 05, 2016 at 02:40:16PM +, Mike McQuaid wrote: > >> Homebrew has a series of convoluted .gitignore rules due to our >> special/weird use-case of wanting to ignore everything in a working >

Re: Git 2.7.0 gitignore behaviour regression

it’s also a big area where libgit2 was inconsistent with Git’s behaviour on either of those versions too. I’ve played around and now got a .gitignore file that behaves consistently across Git 2.6, Git 2.7 and libgit2 0.23.4 (https://github.com/Homebrew/homebrew/blob/master/.gitignore) so ther

Re: Git 2.7.0 gitignore behaviour regression

On Wed, Jan 6, 2016 at 4:50 PM, Mike McQuaid <m...@mikemcquaid.com> wrote: > it’s also a big area where libgit2 was inconsistent with Git’s behaviour on > either of those versions too. Yeah.. it looks like libgit2's gitignore support was written new, not imported from C Git,

Re: Git 2.7.0 gitignore behaviour regression

> Yeah.. it looks like libgit2's gitignore support was written new, not > imported from C Git, so behavior differences (especially in corner > cases) and even lack of some feature ("**" support comes to mind). For > isolated features like gitignore, perhaps we can have an op

Re: Git 2.7.0 gitignore behaviour regression

[+cc Carlos and Shawn for libgit2/JGit talk] On Wed, Jan 06, 2016 at 10:58:37AM -0800, Junio C Hamano wrote: > On Wed, Jan 6, 2016 at 2:03 AM, Duy Nguyen <pclo...@gmail.com> wrote: > > > > Yeah.. it looks like libgit2's gitignore support was written new, not > > impor

Re: Git 2.7.0 gitignore behaviour regression

On Thu, Jan 7, 2016 at 9:04 AM, Jeff King wrote: >> Yup, an area that is reasonably isolated from the remainder of the system >> like >> this might be a good starting point. But I suspect that the invasion needs to >> happen in the opposite direction in this particular case before

Git 2.7.0 gitignore behaviour regression

Hi folks, Firstly, thanks for all your hard work on Git. It makes my life much easier. Homebrew has a series of convoluted .gitignore rules due to our special/weird use-case of wanting to ignore everything in a working directory except a select few files/directories. We experienced a bug

Re: Git 2.7.0 gitignore behaviour regression

On Tue, Jan 05, 2016 at 02:40:16PM +, Mike McQuaid wrote: > Homebrew has a series of convoluted .gitignore rules due to our > special/weird use-case of wanting to ignore everything in a working > directory except a select few files/directories. We experienced a bug > with our .gi

Re: submodule: allow submodule directory in gitignore

odules 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 >> * >> !*/ >> >> Now, I'm trying to add a submodule to my repository, but

Re: submodule: allow submodule directory in gitignore

2015-10-12 14:30 GMT+08:00 Aleksey Komarov <leee...@gmail.com>: > 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

Re: submodule: allow submodule directory in gitignore

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 a

submodule: allow submodule directory in gitignore

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

Re: Single brackets matching in .gitignore rules

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

Re: Single brackets matching in .gitignore rules

gt; > too) >> >> What exactly are you suggesting to "fix", though? Barf when an >> unmatched ] appears as a part of the pattern, instead of taking it >> literally? > > I would rather treat the opened but unmatched [ bracket literally, so > that it works similar li

Re: Single brackets matching in .gitignore rules

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

Re: Single brackets matching in .gitignore rules

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: > >

Re: Single brackets matching in .gitignore rules

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

Re: Single brackets matching in .gitignore rules

Andrey Loskutov writes: > Next, the surprising table for ']': > -- > rule | file | match? > -- > ] ] true > ]* ] true > *] ] true > *] a]true > -- >

Single brackets matching in .gitignore rules

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

Re: [PATCH v3 0/2] gitignore, re-inclusion fix

This round is very clearly explained and I like it very much ;-) Thanks for fixing this. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] gitignore, re-inclusion fix

ry is excluded, the -following conditions must be met: +To re-include files or directories when their parent directory is +excluded, the following conditions must be met: + + - The rules to exclude a directory and re-include a subset back must + be in the same .gitignore file. - The direct

[PATCH v2 0/2] gitignore, re-inclusion fix

No code change. Explain why 1/2 is needed in the commit message. Nguyễn Thái Ngọc Duy (2): dir.c: make last_exclude_matching_from_list() run til the end dir.c: don't exclude whole dir prematurely if neg pattern may match Documentation/gitignore.txt| 21 ++--- dir.c

[PATCH 0/2] gitignore, re-inclusion fix

This is an old problem. I attempted once [1] and then was reminded [2] with some more comments on the original patch. Let's try again. The problem is this .gitignore currently does not work, but it should: /abc !/abc/def/ghi This patch fixes that by realizing that the last rule may re-include

[PATCH v2 02/16] .gitignore: improve MSVC ignore patterns

Add the Microsoft .manifest pattern, and correct the generic 'Debug' and 'Release' directory patterns which were mechanically adjusted way back in c591d5f (gitignore: root most patterns at the top-level directory, 2009-10-26) to allow multi-level projects within the Git suite. Signed-off

[PATCH v2 03/16] .gitignore: ignore library directories created by MSVC VS2008 buildsystem

Signed-off-by: Philip Oakley philipoak...@iee.org --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 91e75ee..e35c492 100644 --- a/.gitignore +++ b/.gitignore @@ -178,6 +178,7 @@ /gitweb/gitweb.cgi /gitweb/static/gitweb.js /gitweb/static

Re: [PATCH 01/17] .gitignore: improve MSVC ignore patterns

From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: Add the Microsoft .manifest pattern, and correct the generic 'Debug' and 'Release' directory patterns which were mechanically adjusted way back in c591d5f (gitignore: root most patterns at the top-level

Re: [PATCH 01/17] .gitignore: improve MSVC ignore patterns

Philip Oakley philipoak...@iee.org writes: Debug/ Release/ suffice? Probably. I was thinking of the 'at any level' aspect... Yeah, that is exactly the difference between rooted /Debug/ and Debug/ ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message

Re: [PATCH 01/17] .gitignore: improve MSVC ignore patterns

Philip Oakley philipoak...@iee.org writes: Add the Microsoft .manifest pattern, and correct the generic 'Debug' and 'Release' directory patterns which were mechanically adjusted way back in c591d5f (gitignore: root most patterns at the top-level directory, 2009-10-26) to allow multi-level

[PATCH 02/17] .gitignore: ignore library directories created by MSVC VS2008 buildsystem

Signed-off-by: Philip Oakley philipoak...@iee.org --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 55498c1..706d0d9 100644 --- a/.gitignore +++ b/.gitignore @@ -177,6 +177,7 @@ /gitweb/gitweb.cgi /gitweb/static/gitweb.js /gitweb/static

[PATCH 01/17] .gitignore: improve MSVC ignore patterns

Add the Microsoft .manifest pattern, and correct the generic 'Debug' and 'Release' directory patterns which were mechanically adjusted way back in c591d5f (gitignore: root most patterns at the top-level directory, 2009-10-26) to allow multi-level projects within the Git suite. Signed-off

Re: Wrong gitignore precedence?

On Wed, 22 Apr 2015 11:59:04 -0700 Junio C Hamano gits...@pobox.com wrote: Swapping the order in the code this late in the game after 8 years may affect people who have come to rely on the current behaviour and never read the doc, which is somewhat worrying, though. I agree. I think the

Wrong gitignore precedence?

Hello All, I read the document of gitignore (http://git-scm.com/docs/gitignore), and learned that $GIT_DIR/info/exclude has higher precedence than the file specified by core.excludesfile. But I noticed that patterns in core.excludesfile override patterns in $GIT_DIR/info/exclude. I tested

Re: Wrong gitignore precedence?

Yohei Endo yoh...@gmail.com writes: I read the document of gitignore (http://git-scm.com/docs/gitignore), and learned that $GIT_DIR/info/exclude has higher precedence than the file specified by core.excludesfile. But I noticed that patterns in core.excludesfile override patterns in $GIT_DIR

[PATCH 08/24] untracked cache: don't open non-existent .gitignore

This cuts down a signficant number of open(.gitignore) because most directories usually don't have .gitignore files. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- dir.c | 26 +- 1 file changed, 25 insertions

<    1   2   3   4   5   >