Re: the opposite of .gitignore, whitelist
On Fri, Oct 26, 2018 at 01:34:53PM +, 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.
Re: the opposite of .gitignore, whitelist
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: > >> > "lhf...@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
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 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
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: >> > "lhf...@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
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
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
On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote: > On 10/25/18 1:37 AM, Junio C Hamano wrote: > > "lhf...@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
Hi all, On 10/25/18 1:37 AM, Junio C Hamano wrote: > "lhf...@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
"lhf...@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?
the opposite of .gitignore, whitelist
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 -- lhf...@163.com
