Re: [PATCH] gitignore: warn about pointless syntax

From: Jeff King <peff@peff.net>
Date: Jan 10, 2012, 18:51 UTC
Message-ID: <20120110185105.GD15273@sigill.intra.peff.net>
In-Reply-To: <alpine.LNX.2.01.1201100639340.11534@frira.zrqbmnf.qr>

On Tue, Jan 10, 2012 at 06:42:11AM +0100, Jan Engelhardt wrote:

Show 7 quoted lines

> >You only have to implement proper backslash decoding, so I think it is
> >not as hard as reimplementing fnmatch:
> >[...]
> >
> >That being said, if this is such a commonly-requested feature
> 
> Was it actually requested, or did you mean "commonly attempted use"?

Both. I meant in my sentence "if this is such a big problem that we need to add a check for it, then surely it is something people would like to be using". But if you peruse the list archives, you can find several people mentioning that they would like it.

Show 6 quoted lines

> As I see it, foo/**/*.o for example is equal to placing "*.o" in
> foo/.gitignore, so the feature is already implemented, just not
> through the syntax people falsely assume it is. And that is the
> reason for wanting to output a warning. If it was me, I'd even make
> it use error(), because that is the only way to educate people (and
> it works), but alas, some on the list might consider that too harsh.

Those features aren't exactly equivalent. Off the top of my head, I can think of a few reasons to prefer using the top-level:

  - you simply prefer it because it keeps your rules grouped in a more
    logical way

  - you don't control the sub-tree (e.g., it is brought in by sub-tree
    merge, or you have an agreement with other devs not to touch things
    in it. Also, I don't think .gitignores cross submodule boundaries
    currently, but it is something that could happen eventually).

  - you can write more complex rules with "**" that would otherwise
    necessitate writing multiple rules split across directories

Don't get me wrong. I am not a huge proponent of "**", and I could really care less if we implement it or not, and we have survived many years without it. It just seems to me that if it's worth warning about, it's worth implementing.

-Peff