Proposal: Traditionally, Git had two distinct semantics for pathspecs. Anything based on tree-diff (i.e. "log" family of commands when limiting the history by paths or "diff" family of commands limiting the output) used "leading paths match" without globbing support. All others (e.g. "grep", "ls-files") supported globbing. This resulted in subtly inconsistent behaviour when one part of the program collected paths from the index and the working tree while another part of the program used differences between the index and the HEAD, e.g. "git add". Unify "pathspec" semantics to make all of them learn the globbing. Risks: If coded poorly, performance bugs can be introduced to the tree-diff codepath, making it inefficient. Some projects may track a file whose name is asterisk (e.g. "foo/*") and output from "git log 'foo/*'" would look different. Before the change, only commits that touch that exact path would be shown, but after the change, any commit that touch a path underneath "foo/" directory will be shown. This is a backward incompatible change. Migration plan: We could conditionally enable globbing support when implementing unified pathspec API, default to the traditional and inconsisntent behaviour during the 1.7.x series, and flip the default to accept globs everwhere in the 1.8.0 release. Practically, however, nobody sane would track paths that have shell metacharacters in them, so we may not need to do the usual "introduce as an opt-in, warn about incompatibility, and flip the default" migration. -- 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