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@xxxxxxx" <lhf635@xxxxxxx> 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.
