git/pathspec.c, branch v2.13.2

Merge branch 'ps/pathspec-empty-prefix-origin'

2017-04-26T06:39:03Z

A recent update broke "git add -p ../foo" from a subdirectory. * ps/pathspec-empty-prefix-origin: pathspec: honor `PATHSPEC_PREFIX_ORIGIN` with empty prefix

pathspec: fix segfault in clear_pathspec

2017-04-17T01:04:06Z

In 'clear_pathspec()' the incorrect index parameter is used to bound an inner-loop which is used to free a 'struct attr_match' value field. Using the incorrect index parameter (in addition to being incorrect) occasionally causes segmentation faults when attempting to free an invalid pointer. Fix this by using the correct index parameter 'i'. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

pathspec: honor `PATHSPEC_PREFIX_ORIGIN` with empty prefix

2017-04-15T06:55:24Z

Previous to commit 5d8f084a5 (pathspec: simpler logic to prefix original pathspec elements, 2017-01-04), we were always using the computed `match` variable to perform pathspec matching whenever `PATHSPEC_PREFIX_ORIGIN` is set. This is for example useful when passing the parsed pathspecs to other commands, as the computed `match` may contain a pathspec relative to the repository root. The commit changed this logic to only do so when we do have an actual prefix and when literal pathspecs are deactivated. But this change may actually break some commands which expect passed pathspecs to be relative to the repository root. One such case is `git add --patch`, which now fails when using relative paths from a subdirectory. For example if executing "git add -p ../foo.c" in a subdirectory, the `git-add--interactive` command will directly pass "../foo.c" to `git-ls-files`. As ls-files is executed at the repository's root, the command will notice that "../foo.c" is outside the repository and fail. Fix the issue by again using the computed `match` variable when `PATHSPEC_PREFIX_ORIGIN` is set and global literal pathspecs are deactivated. Note that in contrast to previous behavior, we will now always call `prefix_magic` regardless of whether a prefix is actually set. But this is the right thing to do: when the `match` variable has been resolved to the repository's root, it will be set to an empty string. When passing the empty string directly to other commands, it will result in a warning regarding deprecated empty pathspecs. By always adding the prefix magic, we will end up with at least the string ":(prefix:0)" and thus avoid the warning. Signed-off-by: Patrick Steinhardt Acked-by: Brandon Williams Reviewed-by: Duy Nguyen

pathspec: allow escaped query values

2017-03-13T22:28:56Z

In our own .gitattributes file we have attributes such as: *.[ch] whitespace=indent,trail,space When querying for attributes we want to be able to ask for the exact value, i.e. git ls-files :(attr:whitespace=indent,trail,space) should work, but the commas are used in the attr magic to introduce the next attr, such that this query currently fails with fatal: Invalid pathspec magic 'trail' in ':(attr:whitespace=indent,trail,space)' This change allows escaping characters by a backslash, such that the query git ls-files :(attr:whitespace=indent\,trail\,space) will match all path that have the value "indent,trail,space" for the whitespace attribute. To accomplish this, we need to modify two places. First `parse_long_magic` needs to not stop early upon seeing a comma or closing paren that is escaped. As a second step we need to remove any escaping from the attr value. Based on a patch by Stefan Beller Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

pathspec: allow querying for attributes

2017-03-13T22:28:54Z

The pathspec mechanism is extended via the new ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it requires paths to not just match the given pattern but also have the specified attrs attached for them to be chosen. Based on a patch by Stefan Beller Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

pathspec: don't error out on all-exclusionary pathspec patterns

2017-02-10T21:19:40Z

Instead of erroring out and telling the user that they should add a positive pattern that covers everything else, just _do_ that. For commands where we honor the current cwd by default (ie grep, ls-files etc), we make that default positive pathspec be the current working directory. And for commands that default to the whole project (ie diff, log, etc), the default positive pathspec is the whole project. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

pathspec magic: add '^' as alias for '!'

2017-02-10T21:19:10Z

The choice of '!' for a negative pathspec ends up not only not matching what we do for revisions, it's also a horrible character for shell expansion since it needs quoting. So add '^' as an alternative alias for an excluding pathspec entry. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

pathspec: give better message for submodule related pathspec error

2017-01-09T23:19:22Z

Every once in a while someone complains to the mailing list to have run into this weird assertion[1]. The usual response from the mailing list is link to old discussions[2], and acknowledging the problem stating it is known. This patch accomplishes two things: 1. Switch assert() to die("BUG") to give a more readable message. 2. Take one of the cases where we hit a BUG and turn it into a normal "there was something wrong with the input" message. This assertion triggered for cases where there wasn't a programming bug, but just bogus input. In particular, if the user asks for a pathspec that is inside a submodule, we shouldn't assert() or die("BUG"); we should tell the user their request is bogus. The only reason we did not check for it, is the expensive nature of such a check, so callers avoid setting the flag PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE. However when we die due to bogus input, the expense of CPU cycles spent outweighs the user wondering what went wrong, so run that check unconditionally before dying with a more generic error message. Note: There is a case (e.g. "git -C submodule add .") in which we call strip_submodule_slash_expensive, as git-add requests it via the flag PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE, but the assert used to trigger nevertheless, because the flag PATHSPEC_LITERAL was not set, such that we executed if (item->nowildcard_len < prefixlen) item->nowildcard_len = prefixlen; and prefixlen was not adapted (e.g. it was computed from "submodule/") So in the die_inside_submodule_path function we also need handle paths, that were stripped before, i.e. are the exact submodule path. This is why the conditions in die_inside_submodule_path are slightly different than in strip_submodule_slash_expensive. [1] https://www.google.com/search?q=item-%3Enowildcard_len [2] http://git.661346.n2.nabble.com/assert-failed-in-submodule-edge-case-td7628687.html https://www.spinics.net/lists/git/msg249473.html Helped-by: Jeff King Helped-by: Junio C Hamano Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

pathspec: rename prefix_pathspec to init_pathspec_item

2017-01-09T02:04:18Z

Give a more relevant name to the prefix_pathspec function as it does more than just prefix a pathspec element. Signed-off-by: Brandon Williams Reviewed-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

pathspec: small readability changes

2017-01-09T02:04:18Z

A few small changes to improve readability. This is done by grouping related assignments, adding blank lines, ensuring lines are <80 characters, and adding additional comments. Signed-off-by: Brandon Williams Reviewed-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano