kernel/git - git - PowerEL Git System

Tree: 702088afc6

Author	SHA1	Message	Date
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 Schindelin	ece7b74903	apply --index-info: fall back to current index for mode changes "git diff" does not record index lines for pure mode changes (i.e. no lines changed). Therefore, apply --index-info would call out a bogus error. Instead, fall back to reading the info from the current index. Incidentally, this fixes an error where git-rebase would not rebase a commit including a pure mode change, and changes requiring a threeway merge. Noticed and later tested by Chris Shoemaker. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Johannes Sixt	1308c17b3e	Allow rebase to run if upstream is completely merged Consider this history: o--o-...-B <- origin \ \ x--x--M--x--x <- master In this situation, rebase considers master fully up-to-date and would not do anything. However, if there were additional commits on origin, the rebase would run and move the commits x on top of origin. Here we change rebase to short-circuit out only if the history since origin is strictly linear. Consequently, the above as well as a history like this would be linearized: o--o <- origin \ x--x \ \ x--M--x--x <- master Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> 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
Amos Waterland	294c695d8c	git rebase loses author name/email if given bad email address If GIT_AUTHOR_EMAIL is of a certain form, `git rebase master' will blow away the author name and email when fast-forward merging commits. I have not tracked it down, but here is a testcase that demonstrates the behavior. Signed-off-by: Amos Waterland <apw@us.ibm.com> Acked-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago