{"thread":{"id":"49667","subject":"the opposite of .gitignore, whitelist","startedAt":"2018-10-25T02:39:38Z","lastAt":"2018-10-26T15:28:03Z","messageCount":10,"participants":["lhf635@163.com","Junio C Hamano","Jason Cooper","Jeff King","Mischa POSLAWSKY","Ævar Arnfjörð Bjarmason","Rafael Ascensão"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"361447","messageId":"201810251039388653199@163.com","threadId":"49667","inReplyTo":null,"subject":"the opposite of .gitignore, whitelist","fromName":"lhf635@163.com","fromEmail":"lhf635@163.com","sentAt":"2018-10-25T02:39:39Z","receivedAt":"2018-10-25T02:39:38Z","isPatch":false,"sender":{"key":"lhf635@163.com","avatar":null},"body":"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\n--------------\nlhf635@163.com"},{"id":"361473","messageId":"xmqqh8hak2mh.fsf@gitster-ct.c.googlers.com","threadId":"49667","inReplyTo":"201810251039388653199@163.com","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-25T05:37:58Z","receivedAt":"2018-10-25T05:38:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"lhf635@163.com\" writes:\n\n> I have a good idea, add a file to git that is the opposite of .gitignore...,\n\nDo negative patterns in .gitignore file help without inventing\nanything new?\n"},{"id":"361517","messageId":"c166b421-a228-8349-0815-2ebb9dcab998@lakedaemon.net","threadId":"49667","inReplyTo":"xmqqh8hak2mh.fsf@gitster-ct.c.googlers.com","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Jason Cooper","fromEmail":"jason@lakedaemon.net","sentAt":"2018-10-25T14:38:46Z","receivedAt":"2018-10-25T14:55:01Z","isPatch":false,"sender":{"key":"jason@lakedaemon.net","avatar":null},"body":"Hi all,\n\n\nOn 10/25/18 1:37 AM, Junio C Hamano wrote:\n> \"lhf635@163.com\" writes:\n>\n>> I have a good idea, add a file to git that is the opposite of .gitignore...,\n> Do negative patterns in .gitignore file help without inventing\n> anything new?\nI did this several years ago in an attempt to track /etc/ (minus\nownership, of course) without storing secrets in the git history.  As\nthe system grew and was maintained (read: crap added), the negative\npatterns grew untenable.  I quickly realized it wasn't the correct way\nto solve the problem.\n\nUnfortunately, shortly after realizing this, I left that project.  So I\nnever had the chance to develop a proper solution.  However, the concept\nof a '.gitonly' file was exactly was I was seeking.  So, for what it's\nworth, I've definitely had at least one legit usecase for this feature.\n\nThe usecases tend to center around tracking select files within the\nrootfs of a full-blown operating system.  Or a subset thereof.\n\nhth,\n\nJason.\n\n"},{"id":"361614","messageId":"20181026093644.GA20876@sigill.intra.peff.net","threadId":"49667","inReplyTo":"c166b421-a228-8349-0815-2ebb9dcab998@lakedaemon.net","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-26T09:36:44Z","receivedAt":"2018-10-26T09:36:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:\n\n> On 10/25/18 1:37 AM, Junio C Hamano wrote:\n> > \"lhf635@163.com\" writes:\n> >\n> >> I have a good idea, add a file to git that is the opposite of .gitignore...,\n> > Do negative patterns in .gitignore file help without inventing\n> > anything new?\n> I did this several years ago in an attempt to track /etc/ (minus\n> ownership, of course) without storing secrets in the git history.  As\n> the system grew and was maintained (read: crap added), the negative\n> patterns grew untenable.  I quickly realized it wasn't the correct way\n> to solve the problem.\n> \n> Unfortunately, shortly after realizing this, I left that project.  So I\n> never had the chance to develop a proper solution.  However, the concept\n> of a '.gitonly' file was exactly was I was seeking.  So, for what it's\n> worth, I've definitely had at least one legit usecase for this feature.\n> \n> The usecases tend to center around tracking select files within the\n> rootfs of a full-blown operating system.  Or a subset thereof.\n\nI think what Junio meant is to ignore everything by default, like:\n\n echo '*' >.gitignore\n\nand then selectively use negative patterns (and being in .gitignore,\nthat makes them positive \"yes, include this\") to add things back:\n\n echo 'foo' >>.gitignore\n\nwhich ends up being roughly the same as your .gitonly concept.\n\nI don't offhand remember if you might run into problems where a\nsubdirectory is ignored by the \"*\" and we do not even recurse into it. I\nthink it would work OK as long as you put everything in the top-level\ngitignore, like:\n\n echo 'subdir/file' >>.gitignore\n\nbut I didn't test.\n\n-Peff\n"},{"id":"361615","messageId":"20181026113151.dgjta7tlcjgnttcx@shiar.net","threadId":"49667","inReplyTo":"20181026093644.GA20876@sigill.intra.peff.net","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Mischa POSLAWSKY","fromEmail":"git@shiar.nl","sentAt":"2018-10-26T11:31:51Z","receivedAt":"2018-10-26T11:31:57Z","isPatch":false,"sender":{"key":"git@shiar.nl","avatar":null},"body":"Jeff King wrote 2018-10-26 5:36 (-0400):\n> I think what Junio meant is to ignore everything by default, like:\n> \n> echo '*' >.gitignore\n> \n> and then selectively use negative patterns (and being in .gitignore,\n> that makes them positive \"yes, include this\") to add things back:\n> \n> echo 'foo' >>.gitignore\n> \n> which ends up being roughly the same as your .gitonly concept.\n\nTo clarify, Peff meant to say echo '!foo' to whitelist. See git help ignore.\n\n-- \nMischa\n"},{"id":"361616","messageId":"20181026115358.GA26844@sigill.intra.peff.net","threadId":"49667","inReplyTo":"20181026113151.dgjta7tlcjgnttcx@shiar.net","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-26T11:53:59Z","receivedAt":"2018-10-26T11:54:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 26, 2018 at 01:31:51PM +0200, Mischa POSLAWSKY wrote:\n\n> Jeff King wrote 2018-10-26 5:36 (-0400):\n> > I think what Junio meant is to ignore everything by default, like:\n> > \n> > echo '*' >.gitignore\n> > \n> > and then selectively use negative patterns (and being in .gitignore,\n> > that makes them positive \"yes, include this\") to add things back:\n> > \n> > echo 'foo' >>.gitignore\n> > \n> > which ends up being roughly the same as your .gitonly concept.\n> \n> To clarify, Peff meant to say echo '!foo' to whitelist. See git help ignore.\n\nOops, yes, thank you.\n\n-Peff\n"},{"id":"361618","messageId":"87tvl8lw5d.fsf@evledraar.gmail.com","threadId":"49667","inReplyTo":"20181026093644.GA20876@sigill.intra.peff.net","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-26T12:39:26Z","receivedAt":"2018-10-26T12:39:31Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 26 2018, Jeff King wrote:\n\n> On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:\n>\n>> On 10/25/18 1:37 AM, Junio C Hamano wrote:\n>> > \"lhf635@163.com\" writes:\n>> >\n>> >> I have a good idea, add a file to git that is the opposite of .gitignore...,\n>> > Do negative patterns in .gitignore file help without inventing\n>> > anything new?\n>> I did this several years ago in an attempt to track /etc/ (minus\n>> ownership, of course) without storing secrets in the git history. As\n>> the system grew and was maintained (read: crap added), the negative\n>> patterns grew untenable. I quickly realized it wasn't the correct way\n>> to solve the problem.\n>>\n>> Unfortunately, shortly after realizing this, I left that project. So I\n>> never had the chance to develop a proper solution. However, the concept\n>> of a '.gitonly' file was exactly was I was seeking. So, for what it's\n>> worth, I've definitely had at least one legit usecase for this feature.\n>>\n>> The usecases tend to center around tracking select files within the\n>> rootfs of a full-blown operating system. Or a subset thereof.\n>\n> I think what Junio meant is to ignore everything by default, like:\n>\n> echo '*' >.gitignore\n>\n> and then selectively use negative patterns (and being in .gitignore,\n> that makes them positive \"yes, include this\") to add things back:\n>\n> echo 'foo' >>.gitignore\n>\n> which ends up being roughly the same as your .gitonly concept.\n>\n> I don't offhand remember if you might run into problems where a\n> subdirectory is ignored by the \"*\" and we do not even recurse into it. I\n> think it would work OK as long as you put everything in the top-level\n> gitignore, like:\n>\n> echo 'subdir/file' >>.gitignore\n>\n> but I didn't test.\n\nThis doesn't work, as explained to myself in this commit in a private\nproject I have where I tried this a while ago:\n\n I thought this was a bug:\n\n (\n rm -rf /tmp/git &&\n git init /tmp/git &&\n cd /tmp/git >/dev/null &&\n echo '*' >.gitignore &&\n echo '!*.txt' >>.gitignore &&\n echo '!.gitignore' >>.gitignore &&\n touch foo.png foo.txt &&\n mkdir dir &&\n touch dir/bar.png dir/bar.txt &&\n git add *.txt &&\n git add */*.txt;\n git status --short\n )\n\n But it's a limitation, gitignore(5) says:\n\n It is not possible to re-include a file if a parent directory of\n that file is excluded. Git doesn’t list excluded directories for\n performance reasons, so any patterns on contained files have no\n effect, no matter where they are defined.\n\n So as a hack exclude anything that looks like a file with an\n extension.\n\n 1 file changed, 1 insertion(+), 1 deletion(-)\n .gitignore | 2 +-\n\n modified .gitignore\n @@ -1,3 +1,3 @@\n -*\n +*.*\n !*.gpg\n !.gitignore\n\nI.e. here I'm trying to maintain a repository where I only want\n.gitignore and *.gpg files committed and everything else ignored, but it\nonly works for one directory level.\n\nThere's not a lot of room left in the gitignore syntax, but I suppose we\ncould extend it to add some \"I really mean it\" negative pattern which\nwould override previous patterns even if those previous patterns matched\ndirectories.\n\nJust fixing it as a bug would make the ignore process slower, since we\ncould no longer just ignore directories and would always need to\nrecursively scan them.\n"},{"id":"361622","messageId":"CACUQV5-t5NHwQMC0=TYZVmPT1NSQn_J+Nz+vj4jj9-b=pn9oTw@mail.gmail.com","threadId":"49667","inReplyTo":"87tvl8lw5d.fsf@evledraar.gmail.com","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Rafael Ascensão","fromEmail":"rafa.almas@gmail.com","sentAt":"2018-10-26T13:28:25Z","receivedAt":"2018-10-26T13:29:05Z","isPatch":false,"sender":{"key":"rafa.almas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1923789?v=4"},"body":"One other option is to just use a pattern that matches everything, i.e:\n echo '*' > .gitignore\n\nAnd take advantage that ignore rules do not apply to tracked files.\nSo instead of using an explicit .gitonly, you add files using:\n git add -f \n\nAll files should be ignored except the ones that were forcibly added.\n\nIf needed, git ls-files can be used to list either category.\n\nCheers,\nRafael Ascensão\n"},{"id":"361624","messageId":"20181026133453.GE24185@io.lakedaemon.net","threadId":"49667","inReplyTo":"87tvl8lw5d.fsf@evledraar.gmail.com","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Jason Cooper","fromEmail":"git@lakedaemon.net","sentAt":"2018-10-26T13:34:53Z","receivedAt":"2018-10-26T13:51:03Z","isPatch":false,"sender":{"key":"git@lakedaemon.net","avatar":null},"body":"On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> On Fri, Oct 26 2018, Jeff King wrote:\n> > On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:\n> >> On 10/25/18 1:37 AM, Junio C Hamano wrote:\n> >> > \"lhf635@163.com\" writes:\n> >> >> I have a good idea, add a file to git that is the opposite of .gitignore...,\n> >> >\n> >> > Do negative patterns in .gitignore file help without inventing\n> >> > anything new?\n> >>\n> >> I did this several years ago in an attempt to track /etc/ (minus\n> >> ownership, of course) without storing secrets in the git history. As\n> >> the system grew and was maintained (read: crap added), the negative\n> >> patterns grew untenable. I quickly realized it wasn't the correct way\n> >> to solve the problem.\n> >>\n> >> Unfortunately, shortly after realizing this, I left that project. So I\n> >> never had the chance to develop a proper solution. However, the concept\n> >> of a '.gitonly' file was exactly was I was seeking. So, for what it's\n> >> worth, I've definitely had at least one legit usecase for this feature.\n> >>\n> >> The usecases tend to center around tracking select files within the\n> >> rootfs of a full-blown operating system. Or a subset thereof.\n> >\n> > I think what Junio meant is to ignore everything by default, like:\n> >\n> > echo '*' >.gitignore\n> >\n> > and then selectively use negative patterns (and being in .gitignore,\n> > that makes them positive \"yes, include this\") to add things back:\n> >\n> > echo 'foo' >>.gitignore\n> >\n> > which ends up being roughly the same as your .gitonly concept.\n> >\n> > I don't offhand remember if you might run into problems where a\n> > subdirectory is ignored by the \"*\" and we do not even recurse into it. I\n> > think it would work OK as long as you put everything in the top-level\n> > gitignore, like:\n> >\n> > echo 'subdir/file' >>.gitignore\n> >\n> > but I didn't test.\n> \n> This doesn't work, as explained to myself in this commit in a private\n> project I have where I tried this a while ago:\n> \n> I thought this was a bug:\n> \n> (\n> rm -rf /tmp/git &&\n> git init /tmp/git &&\n> cd /tmp/git >/dev/null &&\n> echo '*' >.gitignore &&\n> echo '!*.txt' >>.gitignore &&\n> echo '!.gitignore' >>.gitignore &&\n> touch foo.png foo.txt &&\n> mkdir dir &&\n> touch dir/bar.png dir/bar.txt &&\n> git add *.txt &&\n> git add */*.txt;\n> git status --short\n> )\n> \n> But it's a limitation, gitignore(5) says:\n> \n> It is not possible to re-include a file if a parent directory of\n> that file is excluded. Git doesn’t list excluded directories for\n> performance reasons, so any patterns on contained files have no\n> effect, no matter where they are defined.\n\nBingo. This is the exact problem I encountered.\n\n> So as a hack exclude anything that looks like a file with an\n> extension.\n> \n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> .gitignore | 2 +-\n> \n> modified .gitignore\n> @@ -1,3 +1,3 @@\n> -*\n> +*.*\n> !*.gpg\n> !.gitignore\n> \n> I.e. here I'm trying to maintain a repository where I only want\n> .gitignore and *.gpg files committed and everything else ignored, but it\n> only works for one directory level.\n\nPerhaps a workflow solution using the existing .gitignore syntax would\nbe to:\n\n - Use a separate .gitignore file per subdirectory\n - Only list a subdirectory in a .gitignore file when you want to\n exclude the entire tree underneath the subdirectory\n\nWhich would give us two things we could warn on:\n\n - If git detects a negative pattern space (file starts with '*')\n - any directories under that .gitignore need their own\n .gitignore\n - any directories listed in the .gitignore shall not have a\n .gitignore within them.\n\nThe warning could then point to the document I alluded to below.\n\n> There's not a lot of room left in the gitignore syntax, but I suppose we\n> could extend it to add some \"I really mean it\" negative pattern which\n> would override previous patterns even if those previous patterns matched\n> directories.\n\nI'd argue against this. This is a rare enough usecase, that it should\nbe possible, but doesn't need to be easy. Extending the syntax will,\nimo, suggest that it's supposed to be easy. I'd rather see an official\ndoc for how to do it properly (maybe I'm on the right track with the\nabove?) with an explanation for why it is the way it is (efficiency,\nrare usecase, etc)\n\n> Just fixing it as a bug would make the ignore process slower, since we\n> could no longer just ignore directories and would always need to\n> recursively scan them.\n\nRight, rare usecases shouldn't impede regular use.\n\n\nthx,\n\nJason.\n"},{"id":"361627","messageId":"20181026152754.GF24185@io.lakedaemon.net","threadId":"49667","inReplyTo":"20181026133453.GE24185@io.lakedaemon.net","subject":"Re: the opposite of .gitignore, whitelist","fromName":"Jason Cooper","fromEmail":"git@lakedaemon.net","sentAt":"2018-10-26T15:27:54Z","receivedAt":"2018-10-26T15:28:03Z","isPatch":false,"sender":{"key":"git@lakedaemon.net","avatar":null},"body":"On Fri, Oct 26, 2018 at 01:34:53PM +0000, Jason Cooper wrote:\n> On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote:\n...\n> > I thought this was a bug:\n> > \n> > (\n> > rm -rf /tmp/git &&\n> > git init /tmp/git &&\n> > cd /tmp/git >/dev/null &&\n> > echo '*' >.gitignore &&\n> > echo '!*.txt' >>.gitignore &&\n> > echo '!.gitignore' >>.gitignore &&\n> > touch foo.png foo.txt &&\n> > mkdir dir &&\n> > touch dir/bar.png dir/bar.txt &&\n> > git add *.txt &&\n> > git add */*.txt;\n> > git status --short\n> > )\n> > \n> > But it's a limitation, gitignore(5) says:\n> > \n> > It is not possible to re-include a file if a parent directory of\n> > that file is excluded. Git doesn’t list excluded directories for\n> > performance reasons, so any patterns on contained files have no\n> > effect, no matter where they are defined.\n> \n> Bingo. This is the exact problem I encountered.\n\n(\n rm -rf /tmp/git &&\n git init /tmp/git &&\n cd /tmp/git >/dev/null &&\n echo '*' >.gitignore &&\n echo '!dir/' >>.gitignore &&\n echo '!*.txt' >>.gitignore &&\n echo '!.gitignore' >>.gitignore &&\n touch foo.png foo.txt &&\n mkdir dir &&\n echo '*' >dir/.gitignore &&\n echo '!*.txt' >>dir/.gitignore &&\n echo '!.gitignore' >>dir/.gitignore &&\n touch dir/bar.png dir/bar.txt &&\n git add *.txt &&\n git add */*.txt;\n git status --short\n)\n\nWell, this wfm...\n\nUgly, but doable.\n\nthx,\n\nJason.\n"}]}