Commit Graph

10 Commits

Author SHA1 Message Date
Elijah Newren
e951e8f6a9 t5407: fix test to cover intended arguments
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>
2018-06-28 13:28:19 -07:00
Junio C Hamano
141ff8f9e7 t5407: use <<- to align the expected output
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22 08:41:31 -07:00
Matthieu Moy
b12d3e904d rebase -i: fix post-rewrite hook with failed exec command
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-22 08:39:02 -07:00
Matthieu Moy
1d968ca698 rebase -i: demonstrate incorrect behavior of post-rewrite
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>
2015-05-22 08:39:01 -07:00
Felipe Contreras
1fee89cedd test: fix post rewrite hook report
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>
2013-06-03 10:01:03 -07:00
Junio C Hamano
ef88ad2387 rebase --skip: correctly wrap-up when skipping the last patch
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-12-22 16:50:28 -08:00
Thomas Rast
0acb62f202 rebase -i: make post-rewrite work for 'edit'
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-28 21:34:40 -07:00
Thomas Rast
b079feed64 rebase -i: invoke post-rewrite hook
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-12 21:55:39 -08:00
Thomas Rast
96e19488f1 rebase: invoke post-rewrite hook
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-12 21:55:39 -08:00
Thomas Rast
6f6bee3ba9 commit --amend: invoke post-rewrite hook
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>
2010-03-12 21:55:39 -08:00