Jan Engelhardt [off-list ref] writes:
On Monday 2012-01-09 23:33, Jeff King wrote:
quoted
On Mon, Jan 09, 2012 at 11:43:21AM -0800, Junio C Hamano wrote:
quoted
quoted
quoted
+static inline void check_bogus_wildcard(const char *file, const char *p)
+{
+ if (strstr(p, "**") == NULL)
+ return;
+ warning(_("Pattern \"%s\" from file \"%s\": Double asterisk does not "
+ "have a special meaning and is interpreted just like a single "
+ "asterisk.\n"), file, p);
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"?
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.
You can either adjust the people, i.e. teach that their "false" assumption
is wrong and the feature they expect is available but not in a way that
they expect.
Or you can adjust the tool to match their expectation.
The point that Peff correctly read between my lines is that in real life,
people are harder to train than tools and often the latter is a better
approach, especially if it does not amount to too much more work than
doing the former.
On Tuesday 2012-01-10 07:01, Junio C Hamano wrote:
quoted
quoted
That being said, if this is such a commonly-requested feature
Was it actually requested, or did you mean "commonly attempted use"?
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.
You can either adjust the people, i.e. teach that their "false" assumption
is wrong and the feature they expect is available but not in a way that
they expect. Or you can adjust the tool to match their expectation.
[...]in real life, people are harder to train than tools[...]
Though, having one more way to do things leads to a certain mess at a
later point, if such mess is not already present. I am thinking here of
the precedent iptables option parser set by removing support for
exclamation marks in odd positions, as it was redundant ("more than 1
way"), was only supported by ~45% of all options and had to be
explicitly invoked at every callsite - so in fact was harder on users
than git would be for **. There were a few mails by people who could not
seem to read error messages, but overall, within 6-9 months, everything
was quiet again. So, that's the empiric result of what teaching-the-tool
would do.
On Tuesday 2012-01-10 08:01, Jan Engelhardt wrote:
quoted
You can either adjust the people, i.e. teach that their "false" assumption
is wrong and the feature they expect is available but not in a way that
they expect. Or you can adjust the tool to match their expectation.
[...]in real life, people are harder to train than tools[...]
Though, having one more way to do things leads to a certain mess at a
later point, if such mess is not already present. I am thinking here of
the precedent iptables option parser set by removing support for
exclamation marks in odd positions, as it was redundant ("more than 1
way"), was only supported by ~45% of all options and had to be
explicitly invoked at every callsite - so in fact was harder on users
than git would be for **. There were a few mails by people who could not
seem to read error messages, but overall, within 6-9 months, everything
was quiet again. So, that's the empiric result of what teaching-the-tool
would do.
~ teaching-the-user would entail - it's factually problemfree.