delta/git.git/t/t1402-check-ref-format.sh, branch jk/remove-remote-helpers-in-python

t1402: work around shell quoting issue on NetBSD

2013-01-08T21:18:49+00:00

The test fails for me on NetBSD 6.0.1 and reports:

	ok 1 - ref name '' is invalid
	ok 2 - ref name '/' is invalid
	ok 3 - ref name '/' is invalid with options --allow-onelevel
	ok 4 - ref name '/' is invalid with options --normalize
	error: bug in the test script: not 2 or 3 parameters to test-expect-success

The alleged bug is in this line:

	invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'

invalid_ref() constructs a test case description using its last argument,
but the shell seems to split it up into two pieces if it contains a
space.  Minimal test case:

	# on NetBSD with /bin/sh
	$ a() { echo $#-$1-$2; }
	$ t="x"; a "${t:+$t}"
	1-x-
	$ t="x y"; a "${t:+$t}"
	2-x-y
	$ t="x y"; a "${t:+x y}"
	1-x y-

	# and with bash
	$ t="x y"; a "${t:+$t}"
	1-x y-
	$ t="x y"; a "${t:+x y}"
	1-x y-

This may be a bug in the shell, but here's a simple workaround: Construct
the description string first and store it in a variable, and then use
that to call test_expect_success().

Signed-off-by: Rene Scharfe 
Signed-off-by: Junio C Hamano

t1402-check-ref-format: skip tests of refs beginning with slash on Windows

2011-10-13T23:05:22+00:00

Bash on Windows converts program arguments that look like absolute POSIX
paths to their Windows form, i.e., drive-letter-colon format. For this
reason, those tests in t1402 that check refs that begin with a slash do not
work as expected on Windows: valid_ref tests are doomed to fail, and
invalid_ref tests fail for the wrong reason (that there is a colon rather
than that they begin with a slash).

Skip these tests.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

Change check_refname_format() to reject unnormalized refnames

2011-10-05T20:45:30+00:00

Since much of the infrastructure does not work correctly with
unnormalized refnames, change check_refname_format() to reject them.

Similarly, change "git check-ref-format" to reject unnormalized
refnames by default.  But add an option --normalize, which causes "git
check-ref-format" to normalize the refname before checking its format,
and print the normalized refname.  This is exactly the behavior of the
old --print option, which is retained but deprecated.

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

Do not allow ".lock" at the end of any refname component

2011-10-05T20:45:30+00:00

Allowing any refname component to end with ".lock" is looking for
trouble; for example,

    $ git br foo.lock/bar
    $ git br foo
    fatal: Unable to create '[...]/.git/refs/heads/foo.lock': File exists.

Therefore, do not allow any refname component to end with ".lock".

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

Change check_ref_format() to take a flags argument

2011-10-05T20:45:29+00:00

Change check_ref_format() to take a flags argument that indicates what
is acceptable in the reference name (analogous to "git
check-ref-format"'s "--allow-onelevel" and "--refspec-pattern").  This
is more convenient for callers and also fixes a failure in the test
suite (and likely elsewhere in the code) by enabling "onelevel" and
"refspec-pattern" to be allowed independently of each other.

Also rename check_ref_format() to check_refname_format() to make it
obvious that it deals with refnames rather than references themselves.

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

git check-ref-format: add options --allow-onelevel and --refspec-pattern

2011-10-05T20:45:29+00:00

Also add tests of the new options.  (Actually, one big reason to add
the new options is to make it easy to test check_ref_format(), though
the options should also be useful to other scripts.)

Interpret the result of check_ref_format() based on which types of
refnames are allowed.  However, because check_ref_format() can only
return a single value, one test case is still broken.  Specifically,
the case "git check-ref-format --onelevel '*'" incorrectly succeeds
because check_ref_format() returns CHECK_REF_FORMAT_ONELEVEL for this
refname even though the refname is also CHECK_REF_FORMAT_WILDCARD.
The type of check that leads to this failure is used elsewhere in
"real" code and could lead to bugs; it will be fixed over the next few
commits.

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

t1402: add some more tests

2011-10-05T20:45:29+00:00

The new tests reflect the status quo.  Soon the rule for "*.lock" in
refname components will be tightened up.

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

Forbid DEL characters in reference names

2011-08-27T18:47:49+00:00

DEL is an ASCII control character and therefore should not be
permitted in reference names.  Add tests for this and other unusual
characters.

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

check-ref-format --print: Normalize refnames that start with slashes

2011-08-25T20:39:38+00:00

When asked if "refs///heads/master" is valid, check-ref-format says "Yes,
it is well formed", and when asked to print canonical form, it shows
"refs/heads/master". This is so that it can be tucked after "$GIT_DIR/"
to form a valid pathname for a loose ref, and we normalize a pathname like
"$GIT_DIR/refs///heads/master" to de-dup the slashes in it.

Similarly, when asked if "/refs/heads/master" is valid, check-ref-format
says "Yes, it is Ok", but the leading slash is not removed when printing,
leading to "$GIT_DIR//refs/heads/master".

Fix it to make sure such leading slashes are removed.  Add tests that such
refnames are accepted and normalized correctly.

Signed-off-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

tests: add missing &&

2010-11-09T19:59:49+00:00

Breaks in a test assertion's && chain can potentially hide
failures from earlier commands in the chain.

Commands intended to fail should be marked with !, test_must_fail, or
test_might_fail.  The examples in this patch do not require that.

Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano