All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter <vmail@mycircuit.org>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: git@vger.kernel.org
Subject: Re: gitignore: how to exclude a directory tree from being ignored
Date: Thu, 01 Oct 2009 18:26:58 +0200	[thread overview]
Message-ID: <4AC4D852.8000502@mycircuit.org> (raw)
In-Reply-To: <4AC4C9DB.2090907@viscovery.net>

Johannes Sixt wrote:
> Peter schrieb:
>   
>>>> 1) I can't have just one .gitignore file in the root dir, if I want to
>>>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>>>     
>>>>         
>>> No, it's not the inversion of the pattern, but the slash (if it is not at
>>> the end) that makes the pattern non-recursive.
>>>
>>>   
>>>       
>> from the gitignore manpage:
>>     
>>>> If the pattern ends with a slash, it is removed for the purpose of
>>>>         
>> the following description, but it would only find a match with a
>> directory. In other words, foo/ will match a directory foo and paths
>> underneath it, but will not match a regular file or a symbolic link foo
>> (this is consistent with the way how pathspec works in general in git). <<
>>
>> Doesn't this mean, that if I say:
>> vendor/
>> matches the directory and ( recursively ) the paths underneath it.?
>>     
>
> The paragraph you are citing is talking about *what* the pattern matches,
> but it says nothing about *where* the pattern matches.
>
> When I was saying "recursively", then I was refering to the "where"
> aspect, not the "what" aspect.
>
> If you have directories
>
>    src/bar/vendor/
>    src/foo/bar/vendor/
>    src/vendor/
>
> and you have the file src/.gitignore with the single pattern
>
>    vendor/
>
> then it applies to recursively ("where") these directories:
>
>    src/bar/vendor/
>    src/foo/bar/vendor/
>    src/vendor/
>
> and everything ("what") below them.
>
> But if the same src/.gitignore has only this pattern:
>
>    bar/vendor/
>
> then it will not match ("where") recursively and only apply to
>
>    src/bar/vendor/
>
> and everything ("what") below it, but will not apply to
>
>    src/foo/bar/vendor/
>
>   
>> And, consequently:
>> !vendor/
>> inverse the exclusion for vendor ( that is: include ) and everything
>> that is contained in it ? ( This is obviously not the case, but this is
>> what I would expect )
>>     
>
> You should update your expectations. ;-)
>
> You think that git starts with the .gitignore files, and somehow applies
> the rules that it finds to all files (perhaps recursively).
>
> But it does not work like this; rather it is in the oppsite direction: git
> starts with a file name, and then checks the rules in the .gitignore files
> that it has available.
>
> For example, take the path "src/vendor/foo.exe". git finds the file
> src/.gitignore and there it sees the pattern "*.exe". The pattern matches,
> and so git obeys the rule (ignores the file). But the pattern "!vendor/"
> does not match (because the path ends with "foo.exe", not "vendor").
>
> Before git had seen the path "src/vendor/foo.exe", it had already seen
> "src/vendor". This time the pattern "!vendor/" did match (because the name
> is identical *and* it is a directory, as per the cited paragraph) and git
> obeyed the rule (which was not to ignore the directory).
>
> -- Hannes
>   

Ok, In fact, my problem therefore derives from the fact that I can't 
specify *what* and *where* for one item in the same .gitignore file. ( 
all *.o files - what - underneath vendor - where )


*.o
!vendor/

The *.o refers to the *what* and !vendor/ to the *where* and this does 
not work. And this seems to be the reasons why we need to split the 
rules over different .gitignore files:

in the root .gitignore:
*.o
and in the vendor/.gitignore:
!*.o
does exactly what I want.

To me , the *where* aspect relates indeed to recursion but the *what* 
aspect perhaps more to pattern matching...

You should update your expectations. ;-)

Done !
At revision 1238945761623511 :-(

Thanks a lot !
Peter

      reply	other threads:[~2009-10-01 16:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-01 11:07 gitignore: how to exclude a directory tree from being ignored Peter
2009-10-01 12:39 ` Johannes Sixt
2009-10-01 13:00   ` Peter
2009-10-01 13:22     ` Johannes Sixt
2009-10-01 14:48       ` Peter
2009-10-01 15:25         ` Johannes Sixt
2009-10-01 16:26           ` Peter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AC4D852.8000502@mycircuit.org \
    --to=vmail@mycircuit.org \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.