Re: [PATCH] gitignore: root most patterns at the top-level directory

From: Jeff King <peff@peff.net>
Date: Oct 30, 2009, 18:24 UTC
Message-ID: <20091030182431.GA19901@coredump.intra.peff.net>
In-Reply-To: <7vmy3cys0f.fsf@alter.siamese.dyndns.org>

On Tue, Oct 27, 2009 at 11:03:28PM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> How does .cvsignore and .svnignore work?  Don't they have the same issue,
> and perhaps worse as I do not recall seeing a way to anchor a pattern to a
> particular directory like we do in their .SCMignore files?  And judging
> from the fact that they can get away with the lack of that "feature", this
> perhaps is not an issue in real life?

Happily, I did not remember how .cvsignore worked and had to go read the documentation. :) The answer is that no, it does not have the recursive feature in the root .cvsignore list at all. But it does apply the repo-wide CVSROOT/cvsignore, the user's ~/.cvsignore, and the environment's $CVSIGNORE to all directories. So it is safe from this problem (though now that I think on it, I think I was once bitten by something similar in the CVSROOT/cvsignore).

SVN implements this with "properties" on the directories. They are not recursive at all. However, it also implements "global-ignores" which applies everywhere.

So no, they don't have the same issue, because they explicitly split the "everywhere" and "this directory" cases into two locations. We wouldn't want to use .git/info/excludes for this, because we do want to support the project shipping some global excludes itself.

> I am actually a bit reluctant to queue this, even though I most likely
> will, and then hope that we will think of a better solution later, at
> which time this file again needs to change.

I am mixed on it, as well. I did see it bite someone, but I think it's very rare, and everyone who reads or touches the file will have to deal with the ugliness every time. If you want to drop the patch, I will not complain.

> For example, it crossed my mind that perhaps we can change the ignore
> rules so that a non-globbing pattern is automatically anchored at the
> current directly but globbing ones are recursive as before.

That makes some sense to me (and in fact when making the patch, it was the rule of thumb I used). Though I think you might want to make it "starts with glob" as the trigger for the rule. We have "git-core-*/?*", which I would expect to still be anchored at the root.

Show 5 quoted lines

> If we do so, there is no need to change the current .gitignore entires.
> You need to spell a concrete filename as a glob pattern that matches only
> one path if you want the recursive behaviour.  E.g. if you have a Makefile
> per subdirectory, each of which generates and includes Makefile.depend
> file, you would write "Makefile.depen[d]" in the toplevel .gitignore file.

While clever, that use of '[d]' seems unneccessarily obscure to me. Why not just give a wildcard for "any subdirectory of me" and do:

  Makefile.depend
  **/Makefile.depend

Since "**" is in common use in other systems, it's pretty clear (to me, anyway, but then I am the one suggesting the syntax ;) ) what that means.

-Peff