git/git-rebase--interactive.sh, branch v2.4.9

Merge branch 'js/rebase-i-clean-up-upon-continue-to-skip' into maint

2015-08-03T17:41:34Z

Abandoning an already applied change in "git rebase -i" with "--continue" left CHERRY_PICK_HEAD and confused later steps. * js/rebase-i-clean-up-upon-continue-to-skip: rebase -i: do not leave a CHERRY_PICK_HEAD file behind t3404: demonstrate CHERRY_PICK_HEAD bug

rebase -i: do not leave a CHERRY_PICK_HEAD file behind

2015-06-29T20:12:43Z

When skipping commits whose changes were already applied via `git rebase --continue`, we need to clean up said file explicitly. The same is not true for `git rebase --skip` because that will execute `git reset --hard` as part of the "skip" handling in git-rebase.sh, even before git-rebase--interactive.sh is called. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'mm/rebase-i-post-rewrite-exec' into maint

2015-06-25T18:02:09Z

"git rebase -i" fired post-rewrite hook when it shouldn't (namely, when it was told to stop sequencing with 'exec' insn). * mm/rebase-i-post-rewrite-exec: t5407: use <<- to align the expected output rebase -i: fix post-rewrite hook with failed exec command rebase -i: demonstrate incorrect behavior of post-rewrite

rebase -i: fix post-rewrite hook with failed exec command

2015-05-22T15:39:02Z

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 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 Signed-off-by: Junio C Hamano

rebase -i: redo tasks that die during cherry-pick

2015-04-29T15:49:22Z

When rebase--interactive processes a task, it removes the item from the todo list and appends it to another list of executed tasks. If a pick (this includes squash and fixup) fails before the index has recorded the changes, take the corresponding item and put it on the todo list again. Otherwise, the changes introduced by the scheduled commit would be lost. That kind of decision is possible since the cherry-pick command signals why it failed to apply the changes of the given commit. Either the changes are recorded in the index using a conflict (return value 1) and rebase does not continue until they are resolved or the changes are not recorded in the index (return value neither 0 nor 1) and rebase has to try again with the same task. Add a test cases for regression testing to the "rebase-interactive" test suite. Signed-off-by: Fabian Ruch Signed-off-by: Phil Hord Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'es/rebase-i-count-todo' into maint

2015-03-23T18:23:17Z

"git rebase -i" recently started to include the number of commits in the insn sheet to be processed, but on a platform that prepends leading whitespaces to "wc -l" output, the numbers are shown with extra whitespaces that aren't necessary. * es/rebase-i-count-todo: rebase-interactive: re-word "item count" comment rebase-interactive: suppress whitespace preceding item count

rebase-interactive: re-word "item count" comment

2015-03-06T20:25:33Z

97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to display an item count in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) # # Commands: # p, pick = use commit # ... However, with the exception of the --edit-todo option, "TODO" is a one-off term, never presented to the user by rebase-interactive in any other context. The item count is in fact the number of commands ("pick", "edit", etc.) remaining on the instruction sheet, and the comment immediately following it talks about "Commands". Consequently, replace "(# TODO item(s))" with the more accurate and meaningful "(# command(s))". Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

rebase-interactive: suppress whitespace preceding item count

2015-03-06T20:11:27Z

97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to compute an item count with 'wc -l' and display it in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) On Mac OS X, however, it renders as: # Rebase 46640c6..5568fd5 onto 46640c6 ( 4 TODO item(s)) since 'wc -l' indents its output with leading spaces. Fix this. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

Merge branch 'ks/rebase-i-abbrev' into maint

2015-03-05T21:12:56Z

The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script

rebase -i: use full object name internally throughout the script

2015-01-22T20:19:47Z

In earlier days, the abbreviated commit object name shown to the end users were generated with hardcoded --abbrev=7; 56895038 (rebase -i: respect core.abbrev, 2013-09-28) tried to make it honor the user specified core.abbrev, but it missed the very initial invocation of the editor. These days, we try to use the full 40-hex object names internally to avoid ambiguity that can arise after rebase starts running. Newly created objects during the rebase may share the same prefix with existing commits listed in the insn sheet. These object names are shortened just before invoking the sequence editor to present the insn sheet to the end user, and then expanded back to full object names when the editor returns. But the code still used the shortened names when preparing the insn sheet for the very first time, resulting "7 hexdigits or more" output to the user. Change the code to use full 40-hex commit object names from the very beginning to make things more uniform. Signed-off-by: Kirill A. Shutemov Signed-off-by: Junio C Hamano