On Tue, Jan 15, 2019 at 4:38 AM Jonathan Nieder wrote:
>
> Hi,
>
> Junio C Hamano wrote:
>
> > Patterns with slash is anchored at
> > one directory, and that directory is the one that has per-directory
> > .gitignore file. Patterns without slash (including a patte
Jonathan Nieder writes:
> https://public-inbox.org/git/2007080926.gc30...@elie.hsd1.il.comcast.net/
>
> Any idea what happened there? Would it be useful for me to rebase
> and revive that series?
No idea what happend there.
Anyway, I quickly read them over and found nothing questionable,
e
Hi,
Junio C Hamano wrote:
> Patterns with slash is anchored at
> one directory, and that directory is the one that has per-directory
> .gitignore file. Patterns without slash (including a pattern that
> ends with but otherwise has no other slash) are supposed to
Maris Razvan writes:
> I was reading the gitignore documentation
> (https://git-scm.com/docs/gitignore), especially the following
> paragraph:
>
> "If the pattern does not contain a slash /, Git treats it as
> a shell glob pattern and checks for a match against
Hello,
I was reading the gitignore documentation
(https://git-scm.com/docs/gitignore), especially the following
paragraph:
"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 location o
On 20 Oct 2018, at 01:03, Duy Nguyen wrote:
>foo**bar would match foobar as well as foo/bar, foo/x/bar and
>foo/x/y/bar... Its behavior is error prone in my opinion. There's also
>some concerns in early iterations of this "**" support that we would
>need to revisit if we want 'rsync' behavior. I'm
On Sat, Oct 20, 2018 at 7:53 AM dana wrote:
>
> On 20 Oct 2018, at 00:26, Duy Nguyen wrote:
> >Which way should we go? I'm leaning towards the second one...
>
> Not sure how much my opinion is worth, but the second option does feel more
> friendly (from a usage perspective) as well as more straig
On 20 Oct 2018, at 00:26, Duy Nguyen wrote:
>Which way should we go? I'm leaning towards the second one...
Not sure how much my opinion is worth, but the second option does feel more
friendly (from a usage perspective) as well as more straight-forward (from a
re-implementation perspective).
Ther
> along
> with other text within the same path component:
>
> **/**$$*.java
> **.orig
> **local.properties
> !**.sha1
>
> The reason it doesn't allow them is that the gitignore documentation
> explicitly
> states that they're invalid:
>
>
On Mon, Oct 15, 2018 at 12:57 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> Our matching function comes from rsync originally, whose manpage says:
> >>
> >> use ’**’ to match anything, including slashes.
> >>
> >> I believe this is accurate as far as the implementation goes.
> >
> >
Duy Nguyen writes:
>> Our matching function comes from rsync originally, whose manpage says:
>>
>> use ’**’ to match anything, including slashes.
>>
>> I believe this is accurate as far as the implementation goes.
>
> No. "**" semantics is not the same as from rsync. The three cases
> "**/",
n the ripgrep bug tracker is that it does
> > not
> > allow patterns like the following real-world examples, where a ** is used
> > along
> > with other text within the same path component:
> >
> > **/**$$*.java
> > **.orig
> > **local.propertie
On 11 Oct 2018, at 06:08, Ævar Arnfjörð Bjarmason wrote:
>Our matching function comes from rsync originally, whose manpage says:
>
> use ’**’ to match anything, including slashes.
>
>I believe this is accurate as far as the implementation goes. You can
>also see the rather exhaustive tests here:
ng
> with other text within the same path component:
>
> **/**$$*.java
> **.orig
> **local.properties
> !**.sha1
>
> The reason it doesn't allow them is that the gitignore documentation
> explicitly
> states that they're invalid:
>
> A leading "**&q
On 11 Oct 2018, at 05:19, dana wrote:
>git itself happily accepts these patterns, however, apparently treating the **
>like a single * without fnmatch(3)'s FNM_PATHNAME flag set (in other words, it
>matches / as a regular character, thus crossing directory boundaries).
Sorry for replying to mysel
ha1
The reason it doesn't allow them is that the gitignore documentation explicitly
states that they're invalid:
A leading "**" followed by a slash means match in all directories...
A trailing "/**" matches everything inside...
A slash followed by two conse
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
>>>
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
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
uot;git add"
>> and/or "git commit -a")|
>>
>>
>>
>> Noticed it when checking an npm package (ignore) that uses the
>> documentation (https://git-scm.com/docs/gitignore) to determine its
>> functionality. It is documented in https://git-
mmit (use "git add"
> and/or "git commit -a")|
>
>
>
> Noticed it when checking an npm package (ignore) that uses the
> documentation (https://git-scm.com/docs/gitignore) to determine its
> functionality. It is documented in https://git-scm.com/book/en/v2/
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
Also here:
https://github.com/kblees/git/commits/kb/gitignore-doc
These two patches were the result of a discussion mid-october [1] that I almost
forgot about...now including an example as suggested by Jeff.
[1] http://thread.gmane.org/gmane.comp.version-control.git/235753/focus=235856
Karsten
23 matches
Mail list logo
