kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Johannes Schindelin	51ef1daa4a	Rename .git/rebase to .git/rebase-apply With git-am, it sounds awkward to have the patches in ".git/rebase/", but for technical reasons, we have to keep the same directory name for git-am and git-rebase. ".git/rebase-apply" seems to be a good compromise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	28ed6e7b32	Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge" Since the files generated and used during a rebase are never to be tracked, they should live in $GIT_DIR. While at it, avoid the rather meaningless term "dotest" to "rebase", and unhide ".dotest-merge". This was wished for on the mailing list, but so far unimplemented. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 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
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
Eric Wong	751eb39590	git-svn: fix dcommit clobbering upstream when committing multiple changes Although dcommit could detect if the first commit in the series would conflict with the HEAD revision in SVN, it could not detect conflicts in further commits it made. Now we rebase each uncommitted change after each revision is committed to SVN to ensure that we are up-to-date. git-rebase will bail out on conflict errors if our next change cannot be applied and committed to SVN cleanly, preventing accidental clobbering of changes on the SVN-side. --no-rebase users will have trouble with this, and are thus warned if they are committing more than one commit. Fixing this for (hopefully uncommon) --no-rebase users would be more complex and will probably happen at a later date. Thanks to David Watson for finding this and the original test. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Michael Spang	7b3fab877d	Work around Subversion race in git-svn tests. Some of the git-svn tests can fail on fast machines due to a race in Subversion: if a file is modified in the same second it was checked out (or in for that matter), Subversion will not consider it modified. This works around the problem by increasing the timestamp by one second before each commit. [jc: with "touch -r -d" replacement from Eric] Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Michael Spang <mspang@uwaterloo.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Eric Wong	b9c8518722	git-svn: remove support for the svn command-line client Using the command-line client was great for prototyping and getting something working quickly. Eventually I found time to study the library documentation and add support for using the libraries which are much faster and more flexible when it comes to supporting new features. Note that we require version 1.1 of the SVN libraries, whereas we supported the command-line svn client down to version 1.0. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Eric Wong	45bf473a7b	git-svn: fix dcommit losing changes when out-of-date from svn There was a bug in dcommit (and commit-diff) which caused deltas to be generated against the latest version of the changed file in a repository, and not the revision we are diffing (the tree) against locally. This bug can cause recent changes to the svn repository to be silently clobbered by git-svn if our repository is out-of-date. Thanks to Steven Grimm for noticing the bug. The (few) people using the commit-diff command are now required to use the -r/--revision argument. dcommit usage is unchanged. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago