summaryrefslogtreecommitdiff
path: root/t/t7504-commit-msg-hook.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-09-08builtin/merge: honor commit-msg hook for mergesLibravatar Stefan Beller1-4/+60
Similar to 65969d43d1 (merge: honor prepare-commit-msg hook, 2011-02-14) merge should also honor the commit-msg hook: When a merge is stopped due to conflicts or --no-commit, the subsequent commit calls the commit-msg hook. However, it is not called after a clean merge. Fix this inconsistency by invoking the hook after clean merges as well. This change is motivated by Gerrit's commit-msg hook to install a ChangeId trailer into the commit message. Without such a ChangeId, Gerrit refuses to accept any commit by default, such that the inconsistency of (not) running the commit-msg hook between commit and merge leads to confusion and might block people from getting their work done. As the githooks man page is very vocal about the possibility of skipping the commit-msg hook via the --no-verify option, implement the option in merge, too. 'git merge --continue' is currently implemented as calling cmd_commit with no further arguments. This works for most other merge related options, such as demonstrated via the --allow-unrelated-histories flag in the test. The --no-verify option however is not remembered across invocations of git-merge. Originally the author assumed an alternative in which the 'git merge --continue' command accepts the --no-verify flag, but that opens up the discussion which flags are allows to the continued merge command and which must be given in the first invocation. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27sequencer: allow the commit-msg hooks to run during a `reword`Libravatar Johannes Schindelin1-1/+1
The `reword` command used to call `git commit` in a manner that asks for the prepare-commit-msg and commit-msg hooks to do their thing. Converting that part of the interactive rebase to C code introduced the regression where those hooks were no longer run. Let's fix this. Note: the flag is called `VERIFY_MSG` instead of the more intuitive `RUN_COMMIT_MSG_HOOKS` to indicate that the flag suppresses the `--no-verify` flag (which may do other things in the future in addition to suppressing the commit message hooks, too). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-22t7504: document regression: reword no longer calls commit-msgLibravatar Johannes Schindelin1-0/+17
The `reword` command of an interactive rebase used to call the commit-msg hooks, but that regressed when we switched to the rebase--helper backed by the sequencer. Noticed by Sebastian Schuberth. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08t/t7504-commit-msg-hook.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-1/+1
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Skip tests that require a filesystem that obeys POSIX permissionsLibravatar Johannes Sixt1-4/+4
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-1/+1
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>
2008-05-05Fix tests breaking when checkout path contains shell metacharactersLibravatar Bryan Donlan1-10/+13
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>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-4/+4
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>
2007-12-10Interactive editor tests for commit-msg hookLibravatar Wincent Colaiuta1-43/+175
Supplement the existing tests for the commit-msg hook (which all use "git commit -m") with tests which use an interactive editor (no -m switch) to ensure that all code paths get tested. At the same time the quoting of some of the existing tests is changed to conform to Junio's recommendations for test style (single quotes used around the test unless there is a compelling reason not to, and the opening quote on the same line as the test_expect and the closing quote in column 1). Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-09Add tests for pre-commit and commit-msg hooksLibravatar Wincent Colaiuta1-0/+88
As desired, these pass for git-commit.sh, fail for builtin-commit (prior to the fixes), and succeeded for builtin-commit (after the fixes). Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>