[RFC] The design of new pathspec features

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

 



For those who haven't followed closely, some coming changes allow us
to extend current pathspec syntax. We should soon be able to do
case-insenstive matching for example, or introduce "**" wildcard that
is currently used by gitignore. I just want to discuss about the new
syntax and behavior.

Many of these are already implemented in [1]. But I don't want you to
bother with buggy code yet. I'll resend it soon after 1.8.2.

--literal-pathspecs
===================

This feature is added by Jeff to disable globbing for all pathspecs. I
want to push it a bit further: disable all pathspec magic. This means
even ":/" is treated literally when --literal-pathspecs is set.
Because the intent behind this, as I understand, is for scripting, it
makes sense to keep it as literal as possible.

:(literal) magic
================

This magic is for people who want simple no-globbing pathspec (*). It
can be used in combination with other magic such as case-insensitive
matching. Incompatible with :(glob) magic below.

Global option --noglob-pathspecs is added to add :(literal) to
all. This is very similar to --literal-pathspecs. It just does not
disable pathspec magic. :(glob) magic overrides this global option.

(*) you can always disable wildcards by quoting them using backslash,
but that's inconvenient

:(glob) magic
=============

This magic is for people who want globbing. However, it does _not_ use
the same matching mechanism the non-magic pathspec does today. It uses
wildmatch(WM_PATHNAME), which basically means '*' does not match
slashes and "**" does.

Global option --glob-pathspecs is added to add :(glob) to all
pathspec. :(literal) magic overrides this global option.

fnmatch without FNM_PATHNAME is deprecated
==========================================

With the two magic above, people can switch between literal and new
globbing. There is no way to regain current matching behavior once
--[no]glob-pathspecs is used. And I think that's a good thing. New
globbing is more powerful than the current one. At some point, I'd
like to switch the matching behavior when neither literal nor magic
pathspec is specified. Either:

 - make it literal by default
 - make it new globbing by default

Which is more often used should be come the default. The question is
which.

Pathspec mnemonic
=================

Are :(literal) and :(glob) used often enough to deserve a short
mnemonic (like :/ is equivalent to :(top))? Which symbols should be
used? We can only use non-alphanumeric here, and '(', ')', ':' and '/'
are taken. It should be friendly to UNIX shell, no quoting is
preferred.

Another magic will come soon: case-insensitive matching. We may want
to reserve a mnemonic symbol for it as well.

We may also want to reserve option shortcuts for --noglob-pathspecs
and --glob-pathspecs. I suspect they'll be used more often.

New way to specify long pathspec magic
======================================

While testing the pathspec magic code, I grow tired of quoting :(glob)
every time because '(' is the start of a new shell. Which is one of
the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
specify long pathspec magic without quoting.

How about making ":q/xxx/" an equivalence of ":(xxx)"? Any character
(except ',') following 'q' is used as separator (similar to s/// from
sed). This violates the guidelines set in glossary-content.txt (only
use non-alphanumeric).

Another step futher is remove support for ":(xxx)" in favor of
":q(xxx)". We can do it today because I don't think anybody is using
":(top)" (the only supported magic) yet.

[1] https://github.com/pclouds/git/tree/parse-pathspec
--
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]