From: Nguyen Thai Ngoc Duy Date: Thu, 24 Mar 2011 07:49:20 GMT Subject: Re: [PATCH] pathspec: reserve some letters after a colon pathspec Message-ID: In-Reply-To: <4D8AEF9B.9050001@drmicha.warpmail.net> 2011/3/24 Michael J Gruber : >> 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. >> And maybe: . ':' to reach the superproject if user's inside a subproject. So '::/foo' means foo at superproject while ':/foo' means foo in the current project, both at root. >>  ... > > I like this a lot, especially the fact that we would have descriptive > long names as well as short versions for a subset! I'll leave it to you to come up with something we can test :) > 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. We probably want textconv applied to :file: only by default, > attributes to match with :file only? It does not hurt to have generic support for everything. 'git ls-files -- :executable:' would be nice, though I'm not sure if I will ever use it. > We already have ":./cdwfile" as in "commit:./cwdfile", and this looks > like a preexisting instance, although it is not ("commit:" gets stripped > and "./cwdfile" is the pathspec). People will probably try something > like "commit:/rootfile", and we may or may not want to support this. > That particular one is easy, but "commit:full-tree:name" has a defined > meaning now... I think we should leave this one out. It's to address a single path. If you bring full pathspec support to it, a pathspec may resolve to multiple paths, which is unwanted. If people want pathspecs, they can do "git cmd commit -- pathspecs" most of the time. -- Duy