summaryrefslogtreecommitdiff
path: root/t/t1004-read-tree-m-u-wf.sh
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-02-14 16:54:36 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-02-14 13:59:25 -0800
commit131f3c96d265d965d6c93280f9666b23b384802c (patch)
treee65e3b604827cf87b6bb8269fd2ec1b87c968edc /t/t1004-read-tree-m-u-wf.sh
parentgrep: do not diagnose misspelt revs with --no-index (diff)
downloadtgif-131f3c96d265d965d6c93280f9666b23b384802c.tar.xz
grep: treat revs the same for --untracked as for --no-index
git-grep has always disallowed grepping in a tree (as opposed to the working directory) with both --untracked and --no-index. But we traditionally did so by first collecting the revs, and then complaining when any were provided. The --no-index option recently learned to detect revs much earlier. This has two user-visible effects: - we don't bother to resolve revision names at all. So when there's a rev/path ambiguity, we always choose to treat it as a path. - likewise, when you do specify a revision without "--", the error you get is "no such path" and not "--untracked cannot be used with revs". The rationale for doing this with --no-index is that it is meant to be used outside a repository, and so parsing revs at all does not make sense. This patch gives --untracked the same treatment. While it _is_ meant to be used in a repository, it is explicitly about grepping the non-repository contents. Telling the user "we found a rev, but you are not allowed to use revs" is not really helpful compared to "we treated your argument as a path, and could not find it". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t1004-read-tree-m-u-wf.sh')
0 files changed, 0 insertions, 0 deletions