All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Jason Cooper <jason@lakedaemon.net>,
	Junio C Hamano <gitster@pobox.com>,
	"lhf635\@163.com" <lhf635@163.com>, git <git@vger.kernel.org>
Subject: Re: the opposite of .gitignore, whitelist
Date: Fri, 26 Oct 2018 14:39:26 +0200	[thread overview]
Message-ID: <87tvl8lw5d.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20181026093644.GA20876@sigill.intra.peff.net>


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:
>> > "lhf635@163.com" <lhf635@163.com> 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.

  parent reply	other threads:[~2018-10-26 12:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-25  2:39 the opposite of .gitignore, whitelist lhf635
2018-10-25  5:37 ` Junio C Hamano
2018-10-25 14:38   ` Jason Cooper
2018-10-26  9:36     ` Jeff King
2018-10-26 11:31       ` Mischa POSLAWSKY
2018-10-26 11:53         ` Jeff King
2018-10-26 12:39       ` Ævar Arnfjörð Bjarmason [this message]
2018-10-26 13:28         ` Rafael Ascensão
2018-10-26 13:34         ` Jason Cooper
2018-10-26 15:27           ` Jason Cooper

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=87tvl8lw5d.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jason@lakedaemon.net \
    --cc=lhf635@163.com \
    --cc=peff@peff.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.