On 04/04, Patrick Steinhardt wrote: > 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 <p...@pks.im> > --- > > This is the second version of [1]. It fixes a bug catched by > Brandon when the pathspec is resolved to the empty string and > improves the test a bit to actually catch this issue.
This version looks good to me. Thanks for fixing that small issue! -- Brandon Williams
