kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Bert Wesarg	7d66f21a1b	for-each-ref: `:short` format for `refname` Tries to shorten the refname to a non-ambiguous name. Szeder Gábor noticed that the git bash completion takes a tremendous amount of time to strip leading components from heads and tags refs (i.e. refs/heads, refs/tags, ...). He proposed a new atom called 'refbasename' which removes at most two leading components from the ref name. I myself, proposed a more dynamic solution, which strips off common leading components with the matched pattern. But the current bash solution and both proposals suffer from one mayor problem: ambiguous refs. A ref is ambiguous, if it resolves to more than one full refs. I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The (short) ref xyzzy can point to both refs. ( Note: Its irrelevant whether the referenced objects are the same or not. ) This proposal solves this by checking for ambiguity of the shorten ref name. The shortening is done with the same rules for resolving refs but in the reverse order. The short name is checked if it resolves to a different ref. To continue the above example, the output would be like this: heads/xyzzy xyzzy So, if you want just tags, xyzzy is not ambiguous, because it will resolve to a tag. If you need the heads you get a also a non-ambiguous short form of the ref. To integrate this new format into the bash completion to get only non-ambiguous refs is beyond the scope of this patch. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Nanako Shiraishi	3604e7c5c6	tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	e276c26b4b	for-each-ref: cope with tags with incomplete lines If you have a tag with a single, incomplete line as its payload, asking git-for-each-ref for its %(body) element accessed a NULL pointer. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jeff King	d2bf48d2ad	improve for-each-ref test script Previously, we did a sanity check by doing for-each-ref using each possible format atom. However, we never checked the actual output produced by that atom, which recently let an obvious bug go undetected for some time. While we're at it, also clean up a few '!' into test_must_fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	3af828634f	tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	41ac414ea2	Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test should succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Sixt	c9ecf4f12a	for-each-ref: Fix quoting style constants. for-each-ref can accept only one quoting style. For this reason it uses OPT_BIT for the quoting style switches so that it is easy to check for more than one bit being set. However, not all symbolic constants were actually single bit values. In particular: $ git for-each-ref --python error: more than one quoting style ? This fixes it. While we are here, let's also remove the space before the question mark. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Lars Hjemli	c899a57c28	for-each-ref: fix setup of option-parsing for --sort The option value for --sort is already a pointer to a pointer to struct ref_sort, so just use it. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Pierre Habouzit	c3428da87f	Make builtin-for-each-ref.c use parse-opts. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Andy Parkins	96b2d4fa92	Add a test script for for-each-ref, including test of date formatting Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago