Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>> One thing that makes it different from Michael's approach is, :/foo
>> will match ':/foo' literally in every directories and foo at top-tree.
>> I feel mildly uncomfortable with it, but it makes it consistent with
>> other wildcards. If no one objects, I'll try to make a patch with this
>> approach.
>
> Maybe I misunderstand which topic you are referring to. I have a patch
> for ":" (to denote repo-root in pathspecs), there's no need to make
> another one for ":/". (I would really prefer to do it myself since I
> brought it up.) I was just waiting for agreement to settle in about
> which prefix to use.
I am not sure if there is any disagreement in the desired semantics
between the two.
Let's clarify by dumping my understanding of what we aim to achieve.
- The user gives ':/<frotz>' and '<xyzzy>' from the command line, in a
subdirectory.
- Internally we chdir() up to the top of the working tree, and the prefix
is set to the path to the subdirectory (with trailing slash);
get_pathspec(prefix, pathspec) is called, where pathspec is often a
later part of argv[] we got from the command line.
- Currently, get_pathspec() gives either:
- the same as incoming pathspec, if <prefix> is NULL (this happens at
the root of the working tree);
- { <prefix>, NULL }, if the incoming pathspec array is empty; or
- an array of strings taken from pathspec, each prefixed with <prefix>.
The list of the resulting strings is the pathspec, relative to the root
of the working tree, and is used to determine if a path matches the
given pathspec. The match traditionally had two semantics (diff-tree
family and everybody else, only the latter group knew about globs), but
an earlier work by Nguyen has taught globs to everybody (at least it
aimed to; we might have leftover cases that we haven't uncovered).
Both the ":/<path>" proposal (or your ":<path>" proposal) changes only a
very small part of the above, namely, "each prefixed with '<prefix>'" is
changed to if the element in original pathspec has the magic colon prefix,
the magic is stripped away, and the remainder becomes the element in the
resulting pathspec array without additional <prefix> in front.
If Nguyen's proposal is to also match ":/<path>" (or ":<path>") literally,
that part should be scrapped. If somebody wants to match such an unusual
path component, it can always be expressed by quoting it as a glob,
i.e. "[:]/<path>" (or "[:]<path").
I am slightly in favor of ":<path>" syntax (than ":/<path>"), but I do not
care too deeply. Either has the same problem that it will be confusing
with existing and well-established syntax (the former would conflict with
"name of the blob in the index", the latter with "name of the commit that
match the regexp).
--
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