aboutsummaryrefslogtreecommitdiff
path: root/t/t3403-rebase-skip.sh
Commit message (Collapse)AuthorAge
* tests: use "git xyzzy" form (t0000 - t3599)Nanako Shiraishi2008-09-03
| | | | | | | Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t/: Use "test_must_fail git" instead of "! git"Stephan Beyer2008-07-13
| | | | | | | | | | | | | | | 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>
* Sane use of test_expect_failureJunio C Hamano2008-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'mh/rebase-skip-hard'Junio C Hamano2007-11-24
|\ | | | | | | | | * mh/rebase-skip-hard: Do git reset --hard HEAD when using git rebase --skip
| * Do git reset --hard HEAD when using git rebase --skipMike Hommey2007-11-11
| | | | | | | | | | | | | | | | | | | | | | When you have a merge conflict and want to bypass the commit causing it, you don't want to care about the dirty state of the working tree. Also, don't git reset --hard HEAD in the rebase-skip test, so that the lack of support for this is detected. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rebase: fix "rebase --continue" breakageJohannes Schindelin2007-11-12
|/ | | | | | | | The --skip case was handled properly when rebasing without --merge, but the --continue case was not. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-02
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* War on whitespaceJunio C Hamano2007-06-07
| | | | | | | | | This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tests: merge-recursive is usable without PythonJunio C Hamano2006-10-27
| | | | | | | Many tests still protected themselves with $no_python; there is no need to do so anymore. Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply --unidiff-zero: loosen sanity checks for --unidiff=0 patchesJunio C Hamano2006-09-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In "git-apply", we have a few sanity checks and heuristics that expects that the patch fed to us is a unified diff with at least one line of context. * When there is no leading context line in a hunk, the hunk must apply at the beginning of the preimage. Similarly, no trailing context means that the hunk is anchored at the end. * We learn a patch deletes the file from a hunk that has no resulting line (i.e. all lines are prefixed with '-') if it has not otherwise been known if the patch deletes the file. Similarly, no old line means the file is being created. And we declare an error condition when the file created by a creation patch already exists, and/or when a deletion patch still leaves content in the file. These sanity checks are good safety measures, but breaks down when people feed a diff generated with --unified=0. This was recently noticed first by Matthew Wilcox and Gerrit Pape. This adds a new flag, --unified-zero, to allow bypassing these checks. If you are in control of the patch generation process, you should not use --unified=0 patch and fix it up with this flag; rather you should try work with a patch with context. But if all you have to work with is a patch without context, this flag may come handy as the last resort. Signed-off-by: Junio C Hamano <junkio@cox.net>
* rebase: allow --skip to work with --mergeEric Wong2006-06-25
Now that we control the merge base selection, we won't be forced into rolling things in that we wanted to skip beforehand. Also, add a test to ensure this all works as intended. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>