{"thread":{"id":"25866","subject":"[RFD] git glossary: define pathspec","startedAt":"2010-11-29T10:13:42Z","lastAt":"2010-11-29T16:27:58Z","messageCount":4,"participants":["Nguyễn Thái Ngọc Duy","Nguyen Thai Ngoc Duy","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"156793","messageId":"1291025622-15335-1-git-send-email-pclouds@gmail.com","threadId":"25866","inReplyTo":null,"subject":"[RFD] git glossary: define pathspec","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-29T10:13:42Z","receivedAt":"2010-11-29T10:13:42Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"As far as I know we have three lightly incompatible pathspec\nimplementations:\n\n1. match_pathspec() in dir.c\n2. tree_interesting() in tree-walk.c\n3. pathspec_matches() in builtin/grep.c\n\nWhat I describe here is match_pathspec(). What I want is a single\npathspec semantics that all three must follow. Or even better, all\nthree will become a single impl.\n\nWe need to point the differences between the three and see how to\nunify them.\n\nsure if #3 can do the same.\n\ndirectories. Therefore \"Documentation\" can't match the directory,\nwhile Documentation/ can. This is no problem to #2. It can be solved\nwith a similar approach to [1], although maybe we can just convert the\nindex to tree-based structure.\n\nAny other differences?\n\nAlso rewording my poor paragraph is welcome.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/162267\n---\n Documentation/glossary-content.txt |   11 +++++++++++\n 1 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt\nindex 1f029f8..22da1b1 100644\n--- a/Documentation/glossary-content.txt\n+++ b/Documentation/glossary-content.txt\n@@ -278,6 +278,17 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n \tof the logical predecessor(s) in the line of development, i.e. its\n \tparents.\n \n+[[def_pathspec]]pathspec::\n+\tPathspec in its simplest form is a literal path to address a\n+\tfile or a blob.\n+\tPathspec can end with a slash. Such pathspec is considered a\n+\tdirectory prefix and will match everything under matched\n+\tdirectory.\n+\tPathspec can contain wildcards such as '*', '?'... Such\n+\tpathspecs, after being matched literally against the entire\n+\tpath, will be matched against the entire path using\n+\tfnmatch(3).\n+\n [[def_pickaxe]]pickaxe::\n \tThe term <<def_pickaxe,pickaxe>> refers to an option to the diffcore\n \troutines that help select changes that add or delete a given text\n-- \n1.7.3.2.316.gda8b3\n"},{"id":"156794","messageId":"AANLkTi=e5ugMb0fs05Nd5J82=Ua5sg9UrGXztN6rH4=C@mail.gmail.com","threadId":"25866","inReplyTo":"1291025622-15335-1-git-send-email-pclouds@gmail.com","subject":"Re: [RFD] git glossary: define pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-29T10:21:30Z","receivedAt":"2010-11-29T10:21:30Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2010/11/29 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:\n> sure if #3 can do the same.\n> ...\n> index to tree-based structure.\n\nWords disappear mysteriously. That part says\n\n#1 can match a wildcard pattern literally (say \"a*\" will match the\nfile named \"a*\"). This is new to me. I don't know if #3 can do the\nsame.\n\n#2 can't match wildcards, which is known for some time.\n\n#1 and #3 can match index. The famous index does not have directories,\nso \"Documentation\" matches that directory well in #2, but won't in #1\nand #3. \"Documentation/\" works in all three. [1] in the previous mail\ncan be used to recreate directories, or we can just move the index to\na tree-based structure.\n-- \nDuy\n"},{"id":"156795","messageId":"AANLkTimoSVgR1UCKQTVW9vt5QhP6sLGCh7taL2LnwZKW@mail.gmail.com","threadId":"25866","inReplyTo":"1291025622-15335-1-git-send-email-pclouds@gmail.com","subject":"Re: [RFD] git glossary: define pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-29T10:26:21Z","receivedAt":"2010-11-29T10:26:21Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2010/11/29 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:\n> [1] http://article.gmane.org/gmane.comp.version-control.git/162267\n\nSorry again. Wrong reference. The correct link should be\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/162269\n-- \nDuy\n"},{"id":"156810","messageId":"20101129162758.GF8037@burratino","threadId":"25866","inReplyTo":"1291025622-15335-1-git-send-email-pclouds@gmail.com","subject":"Re: [RFD] git glossary: define pathspec","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-29T16:27:58Z","receivedAt":"2010-11-29T16:27:58Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyễn Thái Ngọc Duy wrote:\n\n> --- a/Documentation/glossary-content.txt\n> +++ b/Documentation/glossary-content.txt\n> @@ -278,6 +278,17 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n>  \tof the logical predecessor(s) in the line of development, i.e. its\n>  \tparents.\n>  \n> +[[def_pathspec]]pathspec::\n> +\tPathspec in its simplest form is a literal path to address a\n> +\tfile or a blob.\n> +\tPathspec can end with a slash. Such pathspec is considered a\n> +\tdirectory prefix and will match everything under matched\n> +\tdirectory.\n> +\tPathspec can contain wildcards such as '*', '?'... Such\n> +\tpathspecs, after being matched literally against the entire\n> +\tpath, will be matched against the entire path using\n> +\tfnmatch(3).\n> +\n\nPerhaps worth mentioning that these are path specifiers?\n\n pathspec::\n\tPattern used to specify paths.\n\n\tPathspecs are used on the command line of \"git ls-files\", \"git\n\tls-tree\", \"git grep\", \"git checkout\", and many other commands to\n\tlimit the scope of operations to some subset of the tree or\n\tworktree.  See the documentation of each command for whether\n\tpaths are relative to the current directory or toplevel.  The\n\tpathspec syntax is as follows:\n\n\t. any path matches itself\n\t. the pathspec up to the last slash represents a\n\t  directory prefix.  The scope of that pathspec is\n\t  limited to that subtree.\n\t. the rest of the pathspec is a pattern for the remainder\n\t  of the pathname.  Paths relative to the directory\n\t  prefix will be matched against that pattern using fnmatch(3);\n\t  in particular, '*' and '?' _can_ match directory separators.\n\n\tFor example, Documentation/*.jpg will match all .jpg files\n\tin the Documentation subtree,\n\tincluding Documentation/chapter_1/figure_1.jpg.\n\nOf course, I am making the semantics up. :)\n\nHope that helps,\nJonathan\n"}]}