summaryrefslogtreecommitdiff
path: root/git-rebase--interactive.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-03-17Merge branch 'es/rebase-i-count-todo'Libravatar Junio C Hamano1-1/+2
"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
2015-03-06rebase-interactive: re-word "item count" commentLibravatar Eric Sunshine1-1/+1
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 <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06rebase-interactive: suppress whitespace preceding item countLibravatar Eric Sunshine1-0/+1
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 <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17Merge branch 'ks/rebase-i-abbrev'Libravatar Junio C Hamano1-9/+8
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
2015-01-22rebase -i: use full object name internally throughout the scriptLibravatar Kirill A. Shutemov1-9/+8
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 <kirill.shutemov@linux.intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-10Show number of TODO items for interactive rebaseLibravatar Onno Kortmann1-1/+3
During 'rebase -i', one wrong edit in a long rebase session might inadvertently drop commits/items. This change shows the total number of TODO items in the comments after the list. After performing the rebase edit, total item counts can be compared to make sure that no changes have been lost in the edit. Signed-off-by: Onno Kortmann <onno@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16rebase: omit patch-identical commits with --fork-pointLibravatar John Keeping1-1/+1
When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-25Merge branch 'ep/avoid-test-a-o'Libravatar Junio C Hamano1-1/+1
Update tests and scripts to avoid "test ... -a ...", which is often more error-prone than "test ... && test ...". Squashed misconversion fix-up into git-submodule.sh updates. * ep/avoid-test-a-o: git-submodule.sh: avoid "echo" path-like values git-submodule.sh: avoid "test <cond> -a/-o <cond>" t/test-lib-functions.sh: avoid "test <cond> -a/-o <cond>" t/t9814-git-p4-rename.sh: avoid "test <cond> -a/-o <cond>" t/t5538-push-shallow.sh: avoid "test <cond> -a/-o <cond>" t/t5403-post-checkout-hook.sh: avoid "test <cond> -a/-o <cond>" t/t5000-tar-tree.sh: avoid "test <cond> -a/-o <cond>" t/t4102-apply-rename.sh: avoid "test <cond> -a/-o <cond>" t/t0026-eol-config.sh: avoid "test <cond> -a/-o <cond>" t/t0025-crlf-auto.sh: avoid "test <cond> -a/-o <cond>" t/lib-httpd.sh: avoid "test <cond> -a/-o <cond>" git-rebase--interactive.sh: avoid "test <cond> -a/-o <cond>" git-mergetool.sh: avoid "test <cond> -a/-o <cond>" git-bisect.sh: avoid "test <cond> -a/-o <cond>" contrib/examples/git-resolve.sh: avoid "test <cond> -a/-o <cond>" contrib/examples/git-repack.sh: avoid "test <cond> -a/-o <cond>" contrib/examples/git-merge.sh: avoid "test <cond> -a/-o <cond>" contrib/examples/git-commit.sh: avoid "test <cond> -a/-o <cond>" contrib/examples/git-clone.sh: avoid "test <cond> -a/-o <cond>" check_bindir: avoid "test <cond> -a/-o <cond>"
2014-06-16Merge branch 'rr/rebase-autostash-fix'Libravatar Junio C Hamano1-2/+2
* rr/rebase-autostash-fix: rebase -i: test "Nothing to do" case with autostash rebase -i: handle "Nothing to do" case with autostash
2014-06-09git-rebase--interactive.sh: avoid "test <cond> -a/-o <cond>"Libravatar Elia Pinto1-1/+1
The construct is error-prone; "test" being built-in in most modern shells, the reason to avoid "test <cond> && test <cond>" spawning one extra process by using a single "test <cond> -a <cond>" no longer exists. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19rebase -i: handle "Nothing to do" case with autostashLibravatar Ramkumar Ramachandra1-2/+2
When a user invokes $ git rebase -i @~3 with dirty files and rebase.autostash turned on, and exits the $EDITOR with an empty buffer, the autostash fails to apply. Although the primary focus of rr/rebase-autostash was to get the git-rebase--backend.sh scripts to return control to git-rebase.sh, it missed this case in git-rebase--interactive.sh. Since this case is unlike the other cases which return control for housekeeping, assign it a special return status and handle that return value explicitly in git-rebase.sh. Reported-by: Karen Etheridge <ether@cpan.org> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-21Merge branch 'km/avoid-non-function-return-in-rebase'Libravatar Junio C Hamano1-0/+15
Work around /bin/sh that does not like "return" at the top-level of a file that is dot-sourced from inside a function definition. * km/avoid-non-function-return-in-rebase: Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD" rebase: avoid non-function use of "return" on FreeBSD
2014-04-17rebase: avoid non-function use of "return" on FreeBSDLibravatar Kyle J. McKay1-0/+15
Since a1549e10, 15d4bf2e and 01a1e646 (first appearing in v1.8.4) the git-rebase--*.sh scripts have used a "return" to stop execution of the dot-sourced file and return to the "dot" command that dot-sourced it. The /bin/sh utility on FreeBSD however behaves poorly under some circumstances when such a "return" is executed. In particular, if the "dot" command is contained within a function, then when a "return" is executed by the script it runs (that is not itself inside a function), control will return from the function that contains the "dot" command skipping any statements that might follow the dot command inside that function. Commit 99855ddf (first appearing in v1.8.4.1) addresses this by making the "dot" command the last line in the function. Unfortunately the FreeBSD /bin/sh may also execute some statements in the script run by the "dot" command that appear after the troublesome "return". The fix in 99855ddf does not address this problem. For example, if you have script1.sh with these contents: run_script2() { . "$(dirname -- "$0")/script2.sh" _e=$? echo only this line should show [ $_e -eq 5 ] || echo expected status 5 got $_e return 3 } run_script2 e=$? [ $e -eq 3 ] || { echo expected status 3 got $e; exit 1; } And script2.sh with these contents: if [ 5 -gt 3 ]; then return 5 fi case bad in *) echo always shows esac echo should not get here ! : When running script1.sh (e.g. '/bin/sh script1.sh' or './script1.sh' after making it executable), the expected output from a POSIX shell is simply the single line: only this line should show However, when run using FreeBSD's /bin/sh, the following output appears instead: should not get here expected status 3 got 1 Not only did the lines following the "dot" command in the run_script2 function in script1.sh get skipped, but additional lines in script2.sh following the "return" got executed -- but not all of them (e.g. the "echo always shows" line did not run). These issues can be avoided by not using a top-level "return" in script2.sh. If script2.sh is changed to this: main() { if [ 5 -gt 3 ]; then return 5 fi case bad in *) echo always shows esac echo should not get here ! : } main Then it behaves the same when using FreeBSD's /bin/sh as when using other more POSIX compliant /bin/sh implementations. We fix the git-rebase--*.sh scripts in a similar fashion by moving the top-level code that contains "return" statements into its own function and then calling that as the last line in the script. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-25Merge branch 'us/printf-not-echo'Libravatar Junio C Hamano1-1/+1
* us/printf-not-echo: test-lib.sh: do not "echo" caller-supplied strings rebase -i: do not "echo" random user-supplied strings
2014-03-17rebase -i: do not "echo" random user-supplied stringsLibravatar Uwe Storbeck1-1/+1
In some places we "echo" a string that comes from a commit log message, which may have a backslash sequence that is interpreted by the command (POSIX.1 allows this), most notably "dash"'s built-in 'echo'. A commit message which contains the string '\n' (or ends with the string '\c') may result in a garbage line in the todo list of an interactive rebase which causes the rebase to fail. To reproduce the behavior (with dash as /bin/sh): mkdir test && cd test && git init echo 1 >foo && git add foo git commit -m"this commit message ends with '\n'" echo 2 >foo && git commit -a --fixup HEAD git rebase -i --autosquash --root Now the editor opens with garbage in line 3 which has to be removed or the rebase fails. Signed-off-by: Uwe Storbeck <uwe@ibr.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-11rebase: add the --gpg-sign optionLibravatar Nicolas Vigier1-13/+26
Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-26remove #!interpreter line from shell librariesLibravatar Jonathan Nieder1-6/+3
In a shell snippet meant to be sourced by other shell scripts, an opening #! line does more harm than good. The harm: - When the shell library is sourced, the interpreter and options from the #! line are not used. Specifying a particular shell can confuse the reader into thinking it is safe for the shell library to rely on idiosyncrasies of that shell. - Using #! instead of a plain comment drops a helpful visual clue that this is a shell library and not a self-contained script. - Tools such as lintian can use a #! line to tell when an installation script has failed by forgetting to set a script executable. This check does not work if shell libraries also start with a #! line. The good: - Text editors notice the #! line and use it for syntax highlighting if you try to edit the installed scripts (without ".sh" suffix) in place. The use of the #! for file type detection is not needed because Git's shell libraries are meant to be edited in source form (with ".sh" suffix). Replace the opening #! lines with comments. This involves tweaking the test harness's valgrind support to find shell libraries by looking for "# " in the first line instead of "#!" (see v1.7.6-rc3~7, 2011-06-17). Suggested by Russ Allbery through lintian. Thanks to Jeff King and Clemens Buchacher for further analysis. Tested by searching for non-executable scripts with #! line: find . -name .git -prune -o -type f -not -executable | while read file do read line <"$file" case $line in '#!'*) echo "$file" ;; esac done The only remaining scripts found are templates for shell scripts (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests (t/t4034/perl/{pre,post}). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-30rebase -i: respect core.abbrevLibravatar Kirill A. Shutemov1-1/+1
collapse_todo_ids() uses `git rev-parse --short=7' to abbreviate commit ids before showing them to the user in a text editor. Let's drop argument from --short to the configured value instead (still defaulting to 7). Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-11Merge branch 'es/rebase-i-no-abbrev'Libravatar Junio C Hamano1-0/+30
The commit object names in the insn sheet that was prepared at the beginning of "rebase -i" session can become ambiguous as the rebasing progresses and the repository gains more commits. Make sure the internal record is kept with full 40-hex object names. * es/rebase-i-no-abbrev: rebase -i: fix short SHA-1 collision t3404: rebase -i: demonstrate short SHA-1 collision t3404: make tests more self-contained
2013-09-11Merge branch 'rt/rebase-p-no-merge-summary'Libravatar Junio C Hamano1-1/+2
"git rebase -p" internally used the merge machinery, but when rebasing, there should not be a need for merge summary. * rt/rebase-p-no-merge-summary: rebase --preserve-merges: ignore "merge.log" config
2013-09-11Merge branch 'es/rebase-i-respect-core-commentchar'Libravatar Junio C Hamano1-1/+1
"rebase -i" forgot that the comment character can be configurable while reading its insn sheet. * es/rebase-i-respect-core-commentchar: rebase -i: fix cases ignoring core.commentchar
2013-08-25rebase -i: fix short SHA-1 collisionLibravatar Junio C Hamano1-0/+30
The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and then performs its operations upon those shortened values. This can lead to an abort if the SHA-1 of a reworded or edited commit is no longer unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the todo list has the same abbreviated value. For example: edit f00dfad first pick badbeef second If, after editing, the new SHA-1 of "first" also has prefix badbeef, then the subsequent 'pick badbeef second' will fail since badbeef is no longer a unique SHA-1 abbreviation: error: short SHA1 badbeef is ambiguous. fatal: Needed a single revision Invalid commit name: badbeef Fix this problem by expanding the SHA-1's in the todo list before performing the operations. [es: also collapse & expand SHA-1's for --edit-todo; respect core.commentchar in transform_todo_ids(); compose commit message] Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-21rebase --preserve-merges: ignore "merge.log" configLibravatar Ralf Thielow1-1/+2
When "merge.log" config is set, "rebase --preserve-merges" will add the log lines to the message of the rebased merge commit. A rebase should not modify a commit message automatically. Teach "git-rebase" to ignore that configuration by passing "--no-log" to the git-merge call. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-18rebase -i: fix cases ignoring core.commentcharLibravatar Eric Sunshine1-1/+1
180bad3d (rebase -i: respect core.commentchar, 2013-02-11) updated "rebase -i" to honor core.commentchar but missed one instance of hard-coded '#' comment character in skip_unnecessary_picks(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18Merge branch 'rr/rebase-reflog-message-reword'Libravatar Junio C Hamano1-1/+5
"git rebase [-i]" used to leave just "rebase" as its reflog message for some operations. This rewords them to be more informative. * rr/rebase-reflog-message-reword: rebase -i: use a better reflog message rebase: use a better reflog message
2013-07-11Merge branch 'af/rebase-i-merge-options'Libravatar Junio C Hamano1-5/+16
"git rebase -i" now honors --strategy and -X options. * af/rebase-i-merge-options: Do not ignore merge options in interactive rebase
2013-07-02Do not ignore merge options in interactive rebaseLibravatar Arnaud Fontaine1-5/+16
Merge strategy and its options can be specified in `git rebase`, but with `--interactive`, they were completely ignored. Signed-off-by: Arnaud Fontaine <arnau@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27rebase -i: handle fixup! fixup! in --autosquashLibravatar Andrew Pimlott1-5/+20
In rebase -i --autosquash, ignore all "fixup! " or "squash! " after the first. This supports the case when a git commit --fixup/--squash referred to an earlier fixup/squash instead of the original commit (whether intentionally, as when the user expressly meant to note that the commit fixes an earlier fixup; or inadvertently, as when the user meant to refer to the original commit with :/msg; or out of laziness, as when the user could remember how to refer to the fixup but not the original). In the todo list, the full commit message is preserved, in case it provides useful cues to the user. A test helper set_cat_todo_editor is introduced to check this. Helped-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Andrew Pimlott <andrew@pimlott.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23rebase -i: use a better reflog messageLibravatar Ramkumar Ramachandra1-1/+5
Now that the "checkout" invoked internally from "rebase -i" knows to honor GIT_REFLOG_ACTION, we can start to use it to write a better reflog message when "rebase anotherbranch", "rebase --onto branch", etc. internally checks out the new fork point. We will write: rebase -i: checkout master instead of the old rebase -i As all the calls git-rebase--interactive make to underlying git commands that leave reflog messages are preceded by the internal comment_for_reflog helper function, which uses the original value of the GIT_REFLOG_ACTION variable it saw when it first started, the new assignments to GIT_REFLOG_ACTION actively contaminate the value of the variable, knowing that it will be reset to a sane value before it is used again. This does not generally hold true but it should suffice for now. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12rebase -i: return control to caller, for housekeepingLibravatar Ramkumar Ramachandra1-4/+5
Return control to the caller git-rebase.sh to get these two tasks rm -fr "$dotest" git gc --auto done by it. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12rebase -i: don't error out if $state_dir already existsLibravatar Ramkumar Ramachandra1-1/+1
In preparation for a later patch that will create $state_dir/autostash in git-rebase.sh before anything else can happen, change a `mkdir $state_dir` call to `mkdir -p $state_dir`. The change is safe, because this is not a test to detect an in-progress rebase (that is already done much earlier in git-rebase.sh). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-25bash-prompt.sh: show where rebase is at when stoppedLibravatar Zoltan Klinger1-0/+5
When a rebase stops (e.g. interrupted by a merge conflict), it could be useful to know how far a rebase has progressed and how many commits in total this rebase will apply. Teach the __git_ps1() command to display the number of commits so far applied and the total number of commits to be applied, like this: ((3ec0a6a...)|REBASE 2/5) In the example above the rebase has stopped at the second commit due to a merge conflict and there are a total number of five commits to be applied by this rebase. This information can be already obtained from the following files which are being generated during the rebase: GIT_DIR/.git/rebase-merge/msgnum (git-rebase--merge.sh) GIT_DIR/.git/rebase-merge/end (git-rebase--merge.sh) GIT_DIR/.git/rebase-apply/next (git-am.sh) GIT_DIR/.git/rebase-apply/last (git-am.sh) but "rebase -i" does not leave necessary clues. Implement this feature by doing these three things: 1) Modify git-rebase--interactive.sh to also create GIT_DIR/.git/rebase-merge/msgnum GIT_DIR/.git/rebase-merge/end files for the number of commits so far applied and the total number of commits to be applied. 2) Modify git-prompt.sh to read and display info from the above files. 3) Update test t9903-bash-prompt.sh to reflect changes introduced by this patch. Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-17Merge branch 'jk/rebase-i-comment-char'Libravatar Junio C Hamano1-40/+44
Finishing touches to the earlier core.commentchar topic to cover "rebase -i" as well. * jk/rebase-i-comment-char: rebase -i: respect core.commentchar
2013-02-12rebase -i: respect core.commentcharLibravatar John Keeping1-40/+44
Commit eff80a9 (Allow custom "comment char") introduced a custom comment character for commit messages but did not teach git-rebase--interactive to use it. Change git-rebase--interactive to read core.commentchar and use its value when generating commit messages and for the command list. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21Merge branch 'ph/rebase-preserve-all-merges'Libravatar Junio C Hamano1-1/+6
An earlier change to add --keep-empty option broke "git rebase --preserve-merges" and lost merge commits that end up being the same as its parent. * ph/rebase-preserve-all-merges: rebase --preserve-merges: keep all merge commits including empty ones
2013-01-14rebase --preserve-merges: keep all merge commits including empty onesLibravatar Phil Hord1-1/+6
Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20) 'git rebase --preserve-merges' fails to preserve empty merge commits unless --keep-empty is also specified. Merge commits should be preserved in order to preserve the structure of the rebased graph, even if the merge commit does not introduce changes to the parent. Teach rebase not to drop merge commits only because they are empty. A special case which is not handled by this change is for a merge commit whose parents are now the same commit because all the previous different parents have been dropped as a result of this rebase or some previous operation. Signed-off-by: Phil Hord <hordp@cisco.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Merge branch 'aw/rebase-i-edit-todo'Libravatar Junio C Hamano1-13/+40
Teach an option to edit the insn sheet to "git rebase -i". * aw/rebase-i-edit-todo: rebase -i: suggest using --edit-todo to fix an unknown instruction rebase -i: Add tests for "--edit-todo" rebase -i: Teach "--edit-todo" action rebase -i: Refactor help messages for todo file rebase usage: subcommands can not be combined with -i
2012-09-19rebase -i: suggest using --edit-todo to fix an unknown instructionLibravatar Johannes Sixt1-2/+3
We have now an explicit UI to edit the todo sheet and need not disclose the name of the file. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18rebase -i: fix misleading error message after 'exec no-such' instructionLibravatar Johannes Sixt1-0/+4
When the todo sheet of interactive rebase instructs to run a non-existing command, the operation stops with the following error: Execution failed: no-such You can fix the problem, and then run git rebase --continue fatal: 'rebase' appears to be a git command, but we were not able to execute it. Maybe git-rebase is broken? The reason is that the shell that attempted to run the command exits with code 127. rebase--interactive just forwards this code to the caller (the git wrapper). But our smart run-command infrastructure detects this special exit code and turns it into ENOENT, which in turn is interpreted by the git wrapper as if the external command that it just executed did not exist. This is finally translated to the misleading last two lines in error message cited above. Fix it by translating the error code before it is forwarded. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17rebase -i: Teach "--edit-todo" actionLibravatar Andrew Wong1-0/+17
This allows users to edit the todo file while they're stopped in the middle of an interactive rebase. When this action is executed, all comments from the original todo file are stripped, and new help messages are appended to the end. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17rebase -i: Refactor help messages for todo fileLibravatar Andrew Wong1-11/+20
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'maint-1.7.11' into maintLibravatar Junio C Hamano1-2/+1
* maint-1.7.11: Almost 1.7.11.6 gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO rebase -i: use full onto sha1 in reflog sh-setup: protect from exported IFS receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune setup: clarify error messages for file/revisions ambiguity send-email: improve RFC2047 quote parsing fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-09-10Merge branch 'mg/rebase-i-onto-reflog-in-full' into maint-1.7.11Libravatar Junio C Hamano1-2/+1
The reflog entries left by "git rebase" and "git rebase -i" were inconsistent (the interactive one gave an abbreviated object name). * mg/rebase-i-onto-reflog-in-full: rebase -i: use full onto sha1 in reflog
2012-08-29Merge branch 'mg/rebase-i-onto-reflog-in-full'Libravatar Junio C Hamano1-2/+1
The reflog entries left by "git rebase" and "git rebase -i" were inconsistent. * mg/rebase-i-onto-reflog-in-full: rebase -i: use full onto sha1 in reflog
2012-08-10rebase -i: use full onto sha1 in reflogLibravatar Michael J Gruber1-2/+1
'git rebase' uses the full onto sha1 for the reflog message whereas 'git rebase -i' uses the short sha1. This is not only inconsistent, but can lead to problems when the reflog is inspected at a later time at which that abbreviation may have become ambiguous. Make 'rebase -i' use the full onto sha1, as well. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-25Merge branch 'cw/rebase-i-root'Libravatar Junio C Hamano1-12/+13
Finishing touches to the "rebase -i --root" (new feature for 1.7.12). * cw/rebase-i-root: rebase -i: handle fixup of root commit correctly
2012-07-24rebase -i: handle fixup of root commit correctlyLibravatar Chris Webb1-12/+13
There is a bug with git rebase -i --root when a fixup or squash line is applied to the new root. We attempt to amend the commit onto which they apply with git reset --soft HEAD^ followed by a normal commit. Unlike a real commit --amend, this sequence will fail against a root commit as it has no parent. Fix rebase -i to use commit --amend for fixup and squash instead, and add a test for the case of a fixup of the root commit. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-15Merge branch 'cw/rebase-i-root'Libravatar Junio C Hamano1-6/+26
"git rebase [-i] --root $tip" can now be used to rewrite all the history down to the root. * cw/rebase-i-root: t3404: make test 57 work with dash and others Add tests for rebase -i --root without --onto rebase -i: support --root without --onto
2012-07-13Merge branch 'mz/rebase-no-mbox'Libravatar Junio C Hamano1-3/+1
Teach "am --rebasing" codepath to grab authorship, log message and the patch text directly out of existing commits. This will help rebasing commits that have confusing "diff" output in their log messages. * mz/rebase-no-mbox: am: don't call mailinfo if $rebasing am --rebasing: get patch body from commit, not from mailbox rebase --root: print usage on too many args rebase: don't source git-sh-setup twice
2012-06-26rebase -i: support --root without --ontoLibravatar Chris Webb1-6/+26
Allow --root to be specified to rebase -i without --onto, making it possible to edit and re-order all commits right back to the root(s). If there is a conflict to be resolved when applying the first change, the user will expect a sane index and working tree to get sensible behaviour from git-diff and friends, so create a sentinel commit with an empty tree to rebase onto. Automatically squash the sentinel with any commits rebased directly onto it, so they end up as root commits in their own right and retain their authorship and commit message. Implicitly use rebase -i for non-interactive rebase of --root without an --onto argument now that rebase -i can correctly do this. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>