Subject: Re: the opposite of .gitignore, whitelist

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Fri, 26 Oct 2018 14:39:26 +0200

On Fri, Oct 26 2018, Jeff King wrote:

> On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:
>
>> On 10/25/18 1:37 AM, Junio C Hamano wrote:
>> > "[email-masked]" <[email-masked]> writes:
>> >
>> >> I have a good idea, add a file to git that is the opposite of .gitignore...,
>> > Do negative patterns in .gitignore file help without inventing
>> > anything new?
>> I did this several years ago in an attempt to track /etc/ (minus
>> ownership, of course) without storing secrets in the git history. As
>> the system grew and was maintained (read: crap added), the negative
>> patterns grew untenable. I quickly realized it wasn't the correct way
>> to solve the problem.
>>
>> Unfortunately, shortly after realizing this, I left that project. So I
>> never had the chance to develop a proper solution. However, the concept
>> of a '.gitonly' file was exactly was I was seeking. So, for what it's
>> worth, I've definitely had at least one legit usecase for this feature.
>>
>> The usecases tend to center around tracking select files within the
>> rootfs of a full-blown operating system. Or a subset thereof.
>
> I think what Junio meant is to ignore everything by default, like:
>
>   echo '*' >.gitignore
>
> and then selectively use negative patterns (and being in .gitignore,
> that makes them positive "yes, include this") to add things back:
>
>   echo 'foo' >>.gitignore
>
> which ends up being roughly the same as your .gitonly concept.
>
> I don't offhand remember if you might run into problems where a
> subdirectory is ignored by the "*" and we do not even recurse into it. I
> think it would work OK as long as you put everything in the top-level
> gitignore, like:
>
>   echo 'subdir/file' >>.gitignore
>
> but I didn't test.

This doesn't work, as explained to myself in this commit in a private
project I have where I tried this a while ago:

    I thought this was a bug:

        (
            rm -rf /tmp/git &&
            git init /tmp/git &&
            cd /tmp/git >/dev/null &&
            echo '*' >.gitignore &&
            echo '!*.txt' >>.gitignore &&
            echo '!.gitignore' >>.gitignore &&
            touch foo.png foo.txt &&
            mkdir dir &&
            touch dir/bar.png dir/bar.txt &&
            git add *.txt &&
            git add */*.txt;
            git status --short
        )

    But it's a limitation, gitignore(5) says:

        It is not possible to re-include a file if a parent directory of
        that file is excluded. Git doesn’t list excluded directories for
        performance reasons, so any patterns on contained files have no
        effect, no matter where they are defined.

    So as a hack exclude anything that looks like a file with an
    extension.

    1 file changed, 1 insertion(+), 1 deletion(-)
    .gitignore | 2 +-

    modified   .gitignore
    @@ -1,3 +1,3 @@
    -*
    +*.*
     !*.gpg
     !.gitignore

I.e. here I'm trying to maintain a repository where I only want
.gitignore and *.gpg files committed and everything else ignored, but it
only works for one directory level.

There's not a lot of room left in the gitignore syntax, but I suppose we
could extend it to add some "I really mean it" negative pattern which
would override previous patterns even if those previous patterns matched
directories.

Just fixing it as a bug would make the ignore process slower, since we
could no longer just ignore directories and would always need to
recursively scan them.