On Tue, Jan 10, 2012 at 06:42:11AM +0100, Jan Engelhardt wrote:
> >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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html