summaryrefslogtreecommitdiff
path: root/t/t1506-rev-parse-diagnosis.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-06-17i18n: setup: mark strings for translationLibravatar Vasco Almeida1-1/+1
Update tests that compare the strings newly marked for translation to succeed when running under GETTEXT_POISON. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-06setup: make startup_info available everywhereLibravatar Jeff King1-5/+0
Commit a60645f (setup: remember whether repository was found, 2010-08-05) introduced the startup_info structure, which records some parts of the setup_git_directory() process (notably, whether we actually found a repository or not). One of the uses of this data is for functions to behave appropriately based on whether we are in a repo. But the startup_info struct is just a pointer to storage provided by the main program, and the only program that sets it up is the git.c wrapper. Thus builtins have access to startup_info, but externally linked programs do not. Worse, library code which is accessible from both has to be careful about accessing startup_info. This can be used to trigger a die("BUG") via get_sha1(): $ git fast-import <<-\EOF tag foo from HEAD:./whatever EOF fatal: BUG: startup_info struct is not initialized. Obviously that's fairly nonsensical input to feed to fast-import, but we should never hit a die("BUG"). And there may be other ways to trigger it if other non-builtins resolve sha1s. So let's point the storage for startup_info to a static variable in setup.c, making it available to all users of the library code. We _could_ turn startup_info into a regular extern struct, but doing so would mean tweaking all of the existing use sites. So let's leave the pointer indirection in place. We can, however, drop any checks for NULL, as they will always be false (and likewise, we can drop the test covering this case, which was a rather artificial situation using one of the test-* programs). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09rev-parse: correctly diagnose revision errors before "--"Libravatar Jeff King1-0/+24
Rev-parse understands that a "--" may separate revisions and filenames, and that anything after the "--" is taken as-is. However, it does not understand that anything before the token must be a revision (which is the usual rule implemented by the setup_revisions parser). Since rev-parse prefers revisions to files when parsing before the "--", we end up with the correct result (if such an argument is a revision, we parse it as one, and if it is not, it is an error either way). However, we misdiagnose the errors: $ git rev-parse foobar -- >/dev/null fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar -- >/dev/null fatal: bad flag '--' used after filename In both cases, we should know that the real error is that "foobar" is meant to be a revision, but could not be resolved. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-23specifying ranges: we did not mean to make ".." an empty setLibravatar Junio C Hamano1-0/+14
Either end of revision range operator can be omitted to default to HEAD, as in "origin.." (what did I do since I forked) or "..origin" (what did they do since I forked). But the current parser interprets ".." as an empty range "HEAD..HEAD", and worse yet, because ".." does exist on the filesystem, we get this annoying output: $ cd Documentation/howto $ git log .. ;# give me recent commits that touch Documentation/ area. fatal: ambiguous argument '..': both revision and filename Use '--' to separate filenames from revisions Surely we could say "git log ../" or even "git log -- .." to disambiguate, but we shouldn't have to. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-18verify_filename(): ask the caller to chose the kind of diagnosisLibravatar Matthieu Moy1-1/+1
verify_filename() can be called in two different contexts. Either we just tried to interpret a string as an object name, and it fails, so we try looking for a working tree file (i.e. we finished looking at revs that come earlier on the command line, and the next argument must be a pathname), or we _know_ that we are looking for a pathname, and shouldn't even try interpreting the string as an object name. For example, with this change, we get: $ git log COPYING HEAD:inexistant fatal: HEAD:inexistant: no such path in the working tree. Use '-- <path>...' to specify paths that do not exist locally. $ git log HEAD:inexistant fatal: Path 'inexistant' does not exist in 'HEAD' Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-18sha1_name: do not trigger detailed diagnosis for file argumentsLibravatar Matthieu Moy1-0/+11
diagnose_invalid_sha1_path() is meant to be called to diagnose a misspelt <treeish>:<pathname> when <pathname> does not exist in <treeish>. However, the code may call it if <treeish>:<pathname> is invalid (which triggers another call with only_to_die == 1), but for another reason. This happens when calling e.g. git log existing-file HEAD:existing-file because existing-file is a path and not a revision, the code verifies that the arguments that follow to be paths. This leads to an incorrect message like "existing-file does not exist in HEAD", even though the path exists in HEAD. Check that the search for <pathname> in <treeish> fails before triggering the diagnosis. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>