Re: [PATCH] pathspec: reserve some letters after a colon pathspec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/3/24 Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>:
>> 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]