Re: Git ignore help

From: mdconf@seznam.cz <mdconf@seznam.cz>
Date: Mar 24, 2015, 12:46 UTC
Message-ID: <1PE.3lxh4.2cruo5kZ0hh.1L4LoZ@seznam.cz>
In-Reply-To: <CACsJy8DDC2FbKnu7o1cJR6F6Lh-NabaYtMYOKbm0xbn8PuKoEg@mail.gmail.com>

Hi Duy, Eric,

thx a lot. So net net - I can't really achieve this. It feels like something very basic and simple so pretty surprising but guess that's what it is :)

Normally, I'd expect that the functionality will behave like with similar other blacklist/whitelist functionalities in Linux - that the more specific definition overrides the less specific one. And when there are 2 on the same level then one (include or exclude) has the priority by default...

Anyways, what I am still not clear on is how come that including just the 'single level folder' work?

Duy, you wrote:

"This is true. To elaborate, if we have to recurse in excluded directories so that we can include some back, then the reason for excluding is already defeated as we may need to traverse the entire directory structure. However in this particular case where we do know in advance that only certain directories may have "re-include" rules, e.g. "db", "reports" or "scripts", we could keep going for a while."

... so according to that it sounds like including /db, /reports, /scripts should actually also NOT work. But it does work - i.e. when I add the following:

# exclude /*

# except !/db !/reports !/scripts

then any content within those 3 directories (and their sub directories) is included and not ignored...

It ONLY does not work when I add more levels - e.g.:

!/reports/something

In this case neither /reports nor /reports/something or any sub directory is included.

Martin

---------- Původní zpráva ----------
Od: Duy Nguyen 
Komu: Eric Sunshine 
Datum: 24. 3. 2015 10:40:33
Předmět: Re: Git ignore help

On Tue, Mar 24, 2015 at 8:55 AM, Eric Sunshine  wrote:

Show 9 quoted lines

>> e.g. "db", "reports" or "scripts", we could keep going for a while. I
>> think I attempted to do this in the past and failed (don't remember
>> exactly why). Maybe I'll try again some time in future.
>
> I also was pretty sure that you had attempted this, but couldn't find
> a reference to it, so I didn't mention it in my response. However,
> with some more digging, I finally located it[1].
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/259870

Thank you. I only looked at my repo and no branch name suggested it (if only there is google search for a git repository..). So I gave up because of performance reasons again but that was for enabling it unconditionaly. If we enable it via a config variable and the user is made aware of the performance implications, I guess it would be ok. So it's back in my back log.

-- 
Duy