git.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).