summaryrefslogtreecommitdiff
path: root/t/t1506-rev-parse-diagnosis.sh
AgeCommit message (Collapse)AuthorFilesLines
2011-05-09t1507: avoid "${parameter<op>'word'}" inside double-quotesLibravatar Junio C Hamano1-2/+5
Kacper Kornet noticed that a $variable in "word" in the above construct is not substituted by his pdksh. Modern POSIX compliant shells (e.g. dash, ksh, bash) all seem to interpret POSIX "2.6.2 Parameter Expansion" that says "word shall be subjected to tilde expansion, parameter expansion, command substitution, and arithmetic expansion" in ${parameter<op>word}, to mean that the word is expanded as if it appeared in dq pairs, so if the word were "'$variable'" (sans dq) it would expand to a single quote, the value of the $variable and then a single quote. Johannes Sixt reports that the behavior of quoting at the right of :- when the ${...:-...} expansion appears in double-quotes was debated recently at length at the Austin group. We can avoid this issue and future-proof the test by a slight rewrite. Helped-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-03sha1_name: Suggest commit:./file for path in subdirLibravatar Michael J Gruber1-1/+1
Currently, the "Did you mean..." message suggests "commit:fullpath" only. Extend this to show the more convenient "commit:./file" form also. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-03t1506: factor out test for "Did you mean..."Libravatar Michael J Gruber1-5/+12
With the current code, it's a "'"'"'" jungle, and we test only 1 line of the 2 line response. Factor out and test both. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-09get_sha1: teach ":$n:<path>" the same relative path logicLibravatar Junio C Hamano1-0/+24
We taught the object name parser to take ":./<path>", ":../<path>", etc. and understand them to be relative to the current working directory. Given that ":<path>" is just a short-hand for ":0:<path>" (i.e. "take stage #0 of that path"), we should allow ":$n:<path>" to interpret them the same way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-07get_sha1: support relative path ":path" syntaxLibravatar Nguyễn Thái Ngọc Duy1-0/+62
Currently :path and ref:path can be used to refer to a specific object in index or ref respectively. "path" component is absolute path. This patch allows "path" to be written as "./path" or "../path", which is relative to user's original cwd. This does not work in commands for which startup_info is NULL (i.e. non-builtin ones, it seems none of them needs this anyway). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24rev-parse: tests git rev-parse --verify master@{n}, for various nLibravatar Jon Seymour1-0/+9
This commit introduces tests that verify that rev-parse parses master@{n} correctly for various values of n less than, equal to and greater than the number of revisions in the reference log. In particular, these tests check that rev-parse exits with a non-zero status code and prints a message of the following form to stderr. fatal: Log for [^ ]* only has [0-9][0-9]* entries. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07Detailed diagnosis when parsing an object name fails.Libravatar Matthieu Moy1-0/+69
The previous error message was the same in many situations (unknown revision or path not in the working tree). We try to help the user as much as possible to understand the error, especially with the sha1:filename notation. In this case, we say whether the sha1 or the filename is problematic, and diagnose the confusion between relative-to-root and relative-to-$PWD confusion precisely. The 7 new error messages are tested. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>