kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
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
Marcus Griep	f223824943	count-objects: Add total pack size to verbose output Adds the total pack size (including indexes) the verbose count-objects output, floored to the nearest kilobyte. Updates documentation to match this addition. Signed-off-by: Marcus Griep <marcus@griep.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Stephan Beyer	d492b31caf	t/: Use "test_must_fail git" instead of "! git" This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Bryan Donlan	f69e836fab	Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Bryan Donlan	0e46e70462	Don't use the 'export NAME=value' in the test scripts. This form is not portable across all shells, so replace instances of: export FOO=bar with: FOO=bar export FOO Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> 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
Junio C Hamano	3d5c418ff5	git-clone: aggressively optimize local clone behaviour. This changes the behaviour of cloning from a repository on the local machine, by defaulting to "-l" (use hardlinks to share files under .git/objects) and making "-l" a no-op. A new option, --no-hardlinks, is also added to cause file-level copy of files under .git/objects while still avoiding the normal "pack to pipe, then receive and index pack" network transfer overhead. The old behaviour of local cloning without -l nor -s is availble by specifying the source repository with the newly introduced file:///path/to/repo.git/ syntax (i.e. "same as network" cloning). * With --no-hardlinks (i.e. have all .git/objects/ copied via cpio) would not catch the source repository corruption, and also risks corrupted recipient repository if an alpha-particle hits memory cell while indexing and resolving deltas. As long as the recipient is created uncorrupted, you have a good back-up. * same-as-network is expensive, but it would catch the breakage of the source repository. It still risks corrupted recipient repository due to hardware failure. As long as the recipient is created uncorrupted, you have a good back-up. * The new default on the same filesystem, as long as the source repository is healthy, it is very likely that the recipient would be, too. Also it is very cheap. You do not get any back-up benefit, though. None of the method is resilient against the source repository corruption, so let's discount that from the comparison. Then the difference with and without --no-hardlinks matters primarily if you value the back-up benefit or not. If you want to use the cloned repository as a back-up, then it is cheaper to do a clone with --no-hardlinks and two git-fsck (source before clone, recipient after clone) than same-as-network clone, especially as you are likely to do a git-fsck on the recipient if you are so paranoid anyway. Which leads me to believe that being able to use file:/// is probably a good idea, if only for testability, but probably of little practical value. We default to hardlinked clone for everyday use, and paranoids can use --no-hardlinks as a way to make a back-up. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	5be60078c9	Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	df391b192d	git-fsck-objects is now synonym to git-fsck Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Tom Prince	e0d10e1c63	[PATCH] Rename git-repo-config to git-config. Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	e28714c527	Consolidate {receive,fetch}.unpackLimit This allows transfer.unpackLimit to specify what these two configuration variables want to set. We would probably want to deprecate the two separate variables, as I do not see much point in specifying them independently. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	af7cf268f0	fetch-pack: remove --keep-auto and make it the default. This makes git-fetch over git native protocol to automatically decide to keep the downloaded pack if the fetch results in more than 100 objects, just like receive-pack invoked by git-push does. This logic is disabled when --keep is explicitly given from the command line, so that a very small clone still keeps the downloaded pack as before. The 100 threshold can be adjusted with fetch.unpacklimit configuration. We might want to introduce transfer.unpacklimit to consolidate the two unpacklimit variables, which will be a topic for the next patch. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Nicolas Pitre	5c94f87e6b	use 'init' instead of 'init-db' for shipped docs and tools While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	171e800b37	Revert "fix testsuite: make sure they use templates freshly built from the source" This reverts commit `74d20040ca`. Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler, although I unconsciously stayed away from introducing yet another environment variable.	18 years ago
Junio C Hamano	74d20040ca	fix testsuite: make sure they use templates freshly built from the source The initial t/trash repository for testing was created properly but over time we gained many tests that create secondary test repositories with init-db or clone and they were not careful enough. This fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Johannes Schindelin	16ad357910	add tests for shallow stuff Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Eric Wong	1010437d51	t5500-fetch-pack: remove local (bashism) usage. None of the variables seem to conflict, so local was unnecessary. Also replaced ${var:pos:len} with the sed equivalent. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	7f732c632f	t5500: test fix Relying on eye-candy progress bar was fragile to begin with. Run fetch-pack with -k option, and count the objects that are in the pack that were transferred from the other end. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	16139f9035	t5500: adjust to change in pack-object reporting behaviour. Now pack-object is not as chatty when its stderr is not connected to a terminal, so the test needs to be adjusted for that. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	1fdfd05db2	tests: make scripts executable just for consistency. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Johannes Schindelin	6b17c674aa	Implement a test for git-fetch-pack/git-upload-pack This test provides a minimal example of what went wrong with the old git-fetch-pack (and now works beautifully). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

21 Commits (eed1fcd76d8893ab687c700e1729faea025ba7a8)