summaryrefslogtreecommitdiff
path: root/t/t5407-post-rewrite-hook.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-06-28t5407: fix test to cover intended argumentsLibravatar Elijah Newren1-1/+1
Test 8 in t5407 appears to be an accidental exact duplicate of of test 5; the testcode is identical and has identical repo state, but the test description is different and suggests that rebase -m followed by rebase --skip was what was actually supposed to be tested. Modify the test to include the -m option. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22t5407: use <<- to align the expected outputLibravatar Junio C Hamano1-40/+40
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22rebase -i: fix post-rewrite hook with failed exec commandLibravatar Matthieu Moy1-1/+1
Usually, when 'git rebase' stops before completing the rebase, it is to give the user an opportunity to edit a commit (e.g. with the 'edit' command). In such cases, 'git rebase' leaves the sha1 of the commit being rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase --continue' will call the post-rewrite hook with this sha1 as <old-sha1> argument to the post-rewrite hook. The case of 'git rebase' stopping because of a failed 'exec' command is different: it gives the opportunity to the user to examine or fix the failure, but does not stop saying "here's a commit to edit, use --continue when you're done". So, there's no reason to call the post-rewrite hook for 'exec' commands. If the user did rewrite the commit, it would be with 'git commit --amend' which already called the post-rewrite hook. Fix the behavior to leave no stopped-sha file in case of failed exec command, and teach 'git rebase --continue' to skip record_in_rewritten if no stopped-sha file is found. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22rebase -i: demonstrate incorrect behavior of post-rewriteLibravatar Matthieu Moy1-0/+17
The 'exec' command is sending the current commit to stopped-sha, which is supposed to contain the original commit (before rebase). As a result, if an 'exec' command fails, the next 'git rebase --continue' will send the current commit as <old-sha1> to the post-rewrite hook. The test currently fails with : --- expected.data 2015-05-21 17:55:29.000000000 +0000 +++ [...]post-rewrite.data 2015-05-21 17:55:29.000000000 +0000 @@ -1,2 +1,3 @@ 2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab +488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507 Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-03test: fix post rewrite hook reportLibravatar Felipe Contreras1-2/+2
First expected, then actual. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-22rebase --skip: correctly wrap-up when skipping the last patchLibravatar Junio C Hamano1-1/+17
When "rebase --skip" is used to skip the last patch in the series, the code to wrap up the rewrite by copying the notes from old to new commits and also by running the post-rewrite hook was bypassed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28rebase -i: make post-rewrite work for 'edit'Libravatar Thomas Rast1-0/+16
The post-rewrite support, in the form of the call to 'record_in_rewritten', was hidden in the arm where we have to record a new commit for the user. This meant that it was never invoked in the case where the user has already amended the commit by herself. [The test is designed to exercise both arms of the 'if' in question.] Furthermore, recording the stopped-sha (the SHA1 of the commit before the editing) suffered from a cut&paste error from die_with_patch and used the wrong variable, hence it never recorded anything. Noticed by Junio. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-12rebase -i: invoke post-rewrite hookLibravatar Thomas Rast1-0/+101
Aside from the same issue that rebase also has (remembering the original commit across a conflict resolution), rebase -i brings an extra twist: We need to defer writing the rewritten list in the case of {squash,fixup} because their rewritten result should be the last commit in the squashed group. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-12rebase: invoke post-rewrite hookLibravatar Thomas Rast1-0/+30
We have to deal with two separate code paths: a normal rebase, which actually goes through git-am; and rebase {-m|-s}. The only small issue with both is that they need to remember the original sha1 across a possible conflict resolution. rebase -m already puts this information in $dotest/current, and we just introduce a similar file for git-am. Note that in git-am, the hook really only runs when coming from git-rebase: the code path that sets the $dotest/original-commit file is guarded by a test for $dotest/rebasing. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-12commit --amend: invoke post-rewrite hookLibravatar Thomas Rast1-0/+52
The rough structure of run_rewrite_hook() comes from run_receive_hook() in receive-pack. We introduce a --no-post-rewrite option and use it to avoid the hook when called from git-rebase -i 'edit'. The next patch will add full support in git-rebase, and we only want to invoke the hook once. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>