the opposite of .gitignore, whitelist

the opposite of .gitignore, whitelist

[lhf635]

I have a good idea, add a file to git that is the opposite of .gitignore, whitelist, the code in the development directory can be submitted to git version control, you can only submit the source code in the src directory, without concern for development tools and operations.System and other files, after all, the type of each project code is fixed, I am in the community I did not find a way to submit requirements in the community, so
--------------
lhf635@163.com

Re: the opposite of .gitignore, whitelist

[Junio C Hamano]

"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?

Re: the opposite of .gitignore, whitelist

[Jason Cooper]

Hi all,


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.

hth,

Jason.

Re: the opposite of .gitignore, whitelist

[Jeff King]

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.

-Peff

Re: the opposite of .gitignore, whitelist

[Mischa POSLAWSKY]

Jeff King wrote 2018-10-26 5:36 (-0400):
> 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.

To clarify, Peff meant to say echo '!foo' to whitelist. See git help ignore.

-- 
Mischa

Re: the opposite of .gitignore, whitelist

[Jeff King]

On Fri, Oct 26, 2018 at 01:31:51PM +0200, Mischa POSLAWSKY wrote:

> Jeff King wrote 2018-10-26 5:36 (-0400):
> > 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.
> 
> To clarify, Peff meant to say echo '!foo' to whitelist. See git help ignore.

Oops, yes, thank you.

-Peff

Re: the opposite of .gitignore, whitelist

[Ævar Arnfjörð Bjarmason]

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.

Re: the opposite of .gitignore, whitelist

[Rafael Ascensão]

One other option is to just use a pattern that matches everything, i.e:
    echo '*' > .gitignore

And take advantage that ignore rules do not apply to tracked files.
So instead of using an explicit .gitonly, you add files using:
   git add -f <file_to_be_included>

All files should be ignored except the ones that were forcibly added.

If needed, git ls-files can be used to list either category.

Cheers,
Rafael Ascensão

Re: the opposite of .gitignore, whitelist

[Jason Cooper]

On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 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.

Bingo.  This is the exact problem I encountered.

>     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.

Perhaps a workflow solution using the existing .gitignore syntax would
be to:

    - Use a separate .gitignore file per subdirectory
    - Only list a subdirectory in a .gitignore file when you want to
      exclude the entire tree underneath the subdirectory

Which would give us two things we could warn on:

    - If git detects a negative pattern space (file starts with '*')
        - any directories under that .gitignore need their own
          .gitignore
        - any directories listed in the .gitignore shall not have a
          .gitignore within them.

The warning could then point to the document I alluded to below.

> 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.

I'd argue against this.  This is a rare enough usecase, that it should
be possible, but doesn't need to be easy.  Extending the syntax will,
imo, suggest that it's supposed to be easy.  I'd rather see an official
doc for how to do it properly (maybe I'm on the right track with the
above?) with an explanation for why it is the way it is (efficiency,
rare usecase, etc)

> 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.

Right, rare usecases shouldn't impede regular use.


thx,

Jason.

Re: the opposite of .gitignore, whitelist

[Jason Cooper]

On Fri, Oct 26, 2018 at 01:34:53PM +0000, Jason Cooper wrote:
> On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote:
...
> >     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.
> 
> Bingo.  This is the exact problem I encountered.

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

Well, this wfm...

Ugly, but doable.

thx,

Jason.