summaryrefslogtreecommitdiff
path: root/t/t1503-rev-parse-verify.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-10rev-parse: handle --end-of-optionsLibravatar Jeff King1-0/+13
We taught rev-list a new way to separate options from revisions in 19e8789b23 (revision: allow --end-of-options to end option parsing, 2019-08-06), but rev-parse uses its own parser. It should know about --end-of-options not only for consistency, but because it may be presented with similarly ambiguous cases. E.g., if a caller does: git rev-parse "$rev" -- "$path" to parse an untrusted input, then it will get confused if $rev contains an option-like string like "--local-env-vars". Or even "--not-real", which we'd keep as an option to pass along to rev-list. Or even more importantly: git rev-parse --verify "$rev" can be confused by options, even though its purpose is safely parsing untrusted input. On the plus side, it will always fail the --verify part, as it will not have parsed a revision, so the caller will generally "fail closed" rather than continue to use the untrusted string. But it will still trigger whatever option was in "$rev"; this should be mostly harmless, since rev-parse options are all read-only, but I didn't carefully audit all paths. This patch lets callers write: git rev-parse --end-of-options "$rev" -- "$path" and: git rev-parse --verify --end-of-options "$rev" which will both treat "$rev" always as a revision parameter. The latter is a bit clunky. It would be nicer if we had defined "--verify" to require that its next argument be the revision. But we have not historically done so, and: git rev-parse --verify -q "$rev" does currently work. I added a test here to confirm that we didn't break that. A few implementation notes: - We don't document --end-of-options explicitly in commands, but rather in gitcli(7). So I didn't give it its own section in git-rev-parse(1). But I did call it out specifically in the --verify section, and include it in the examples, which should show best practices. - We don't have to re-indent the main option-parsing block, because we can combine our "did we see end of options" check with "does it start with a dash". The exception is the pre-setup options, which need their own block. - We do however have to pull the "--" parsing out of the "does it start with dash" block, because we want to parse it even if we've seen --end-of-options. - We'll leave "--end-of-options" in the output. This is probably not technically necessary, as a careful caller will do: git rev-parse --end-of-options $revs -- $paths and anything in $revs will be resolved to an object id. However, it does help a slightly less careful caller like: git rev-parse --end-of-options $revs_or_paths where a path "--foo" will remain in the output as long as it also exists on disk. In that case, it's helpful to retain --end-of-options to get passed along to rev-list, s it would otherwise see just "--foo". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10files_read_raw_ref: avoid infinite loop on broken symlinksLibravatar Jeff King1-0/+5
Our ref resolution first runs lstat() on any path we try to look up, because we want to treat symlinks specially (by resolving them manually and considering them symrefs). But if the results of `readlink` do _not_ look like a ref, we fall through to treating it like a normal file, and just read the contents of the linked path. Since fcb7c76 (resolve_ref_unsafe(): close race condition reading loose refs, 2013-06-19), that "normal file" code path will stat() the file and if we see ENOENT, will jump back to the lstat(), thinking we've seen inconsistent results between the two calls. But for a symbolic ref, this isn't a race: the lstat() found the symlink, and the stat() is looking at the path it points to. We end up in an infinite loop calling lstat() and stat(). We can fix this by avoiding the retry-on-inconsistent jump when we know that we found a symlink. While we're at it, let's add a comment explaining why the symlink case gets to this code in the first place; without that, it is not obvious that the correct solution isn't to avoid the stat() code path entirely. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-28tests: remove some direct access to .git/logsLibravatar David Turner1-6/+3
Alternate refs backends might store reflogs somewhere other than .git/logs. Change most test code that directly accesses .git/logs to instead use git reflog commands. There are still a few tests which need direct access to reflogs: to check reflog permissions, to manually create reflogs from scratch, to save/restore reflogs, to check the format of raw reflog data, and to remove not just reflog contents, but the reflogs themselves. All cases which don't need direct access have been modified. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-19refs: make rev-parse --quiet actually quietLibravatar David Aguilar1-0/+27
When a reflog is deleted, e.g. when "git stash" clears its stashes, "git rev-parse --verify --quiet" dies: fatal: Log for refs/stash is empty. The reason is that the get_sha1() code path does not allow us to suppress this message. Pass the flags bitfield through get_sha1_with_context() so that read_ref_at() can suppress the message. Use get_sha1_with_context1() instead of get_sha1() in rev-parse so that the --quiet flag is honored. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-16t1503: use test_must_be_emptyLibravatar David Aguilar1-5/+5
Use `test_must_be_be_empty <file>` instead of `test -z "$(cat <file>)"`. Suggested-by: Fabian Ruch <bafain@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27t1503: Fix arithmetic expansion syntax error when using dashLibravatar Ramsay Jones1-2/+2
On systems which have dash as /bin/sh, such as Ubuntu, the final test (master@{n} for various n) fails with a syntax error while processing an arithmetic expansion. The syntax error is caused by using a bare name ('N') as a variable reference in the expression. In order to avoid the syntax error, we spell the variable reference as '$N' rather than simply 'N'. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-31t1503: fix broken test_must_fail callsLibravatar Jon Seymour1-2/+2
Some tests in maint-reflog-beyond-horizon are calling test_must_fail in such a way that the arguments to test_must_fail do, indeed, fail but not in the manner expected by the test. This patch removes the unnecessary and unhelpful double quotes. Signed-off-by: Jon Seymour <jon.seymour@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/+11
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>
2008-09-03tests: use "git xyzzy" form (t0000 - t3599)Libravatar Nanako Shiraishi1-1/+1
Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11rev-parse --verify: do not output anything on errorLibravatar Christian Couder1-9/+3
Before this patch, when "git rev-parse --verify" was passed at least one good rev and then anything, it would output something for the good rev even if it would latter exit on error. With this patch, we only output something if everything is ok. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11rev-parse: fix using "--default" with "--verify"Libravatar Christian Couder1-6/+5
Before this patch, something like: $ git rev-parse --verify HEAD --default master did not work, while: $ git rev-parse --default master --verify HEAD worked. This patch fixes that, so that they both work (assuming HEAD and master can be parsed). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11rev-parse: add test script for "--verify"Libravatar Christian Couder1-0/+114
This patch documents the current behavior of "git rev-parse --verify". This command is tested both with and without the "--quiet" and "--default" options. This shows some problems with the current behavior that will be fixed in latter patches: - in case of errors, there should be no good rev output on stdout, - with "--default" one test case is broken Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>