Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Junio C Hamano venit, vidit, dixit 23.03.2011 19:04: > ... >> Here is a weather-baloon. I will use colon below as the magic introducer, >> as I don't care very deeply about the choice of it. >> >> - "^:([^\w\d]+)(.*)$", that is "a magic introducer followed by a sequence >> of non-alnum followed by the remainder" means that the part that is >> given to the matching engine is $2, and each gibberish character in $1 >> determines what magic is requested when the matching engine does its >> work. Among the gibberish that can be in $1, we currently would want >> to support: >> >> . '/' denotes that $2 is relative to root of the working tree, i.e. do >> not add 'prefix' to it at the left. >> >> . '!' denotes that the matching with $2 should not honor globbing. >> >> e.g. >> >> ":/*lib/**/foo.h", if '*' denoted recursive glob support for '**/' to >> mean "zero-or-more levels of any directory" [*1*], it would find any >> foo.h in a directory 'lib' or its subdirectory that is found in >> anywhere in the working tree. >> >> - "^:((?:[-a-z]+)(?:,[-a-z+]+)*):(.*)$", that is "a magic introducer, >> followed by one or more alpha-string separated with comma, followed >> by a magic terminator, and the remainder" means that the remainder is >> what is given to the matching engine, and the alpha-strings spell out >> the name of the magic. We currently would want to support: >> >> . 'full-tree' means exactly the same as '/' mnemonic above. >> . 'noglob' means exactly the same as '!' mnemonic. >> >> e.g. >> >> ":full-tree,recursive-glob:lib/**/foo.h" would be how you fully spell >> the above example in the mnemonic section [*2*]. > > I like this a lot, especially the fact that we would have descriptive > long names as well as short versions for a subset! Two remarks: > > :(symlink|submodule|directory|file): would fit into that scheme (for use > in .gitattributes), though I'm not sure we want that for general > pathspecs. I do not offhand think it is a good idea. While traversing history the pathspec matcher often does not have the mode information extracted from the tree object in the codepath it inspects the name, so it would be very costly, I don't think it would particularly be useful, and pathspec is about names and not about types. A magic that says "please match case insensitively", so that we do not have to write "git log -- '[Rr][Ee][Aa][Dd][Mm][Ee]'" would be very useful. Perhaps "gibberish" is not a good long term solution after all, as a natural short-hand for that magic would be a single letter 'i' somewhere, similar to (?i) in pcre. -- 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