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

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

Show number of TODO items for interactive rebase

2014-12-10T21:17:38Z

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

rebase: omit patch-identical commits with --fork-point

2014-07-16T20:07:40Z

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

Merge branch 'ep/avoid-test-a-o'

2014-06-25T19:23:56Z

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 -a/-o " t/test-lib-functions.sh: avoid "test -a/-o " t/t9814-git-p4-rename.sh: avoid "test -a/-o " t/t5538-push-shallow.sh: avoid "test -a/-o " t/t5403-post-checkout-hook.sh: avoid "test -a/-o " t/t5000-tar-tree.sh: avoid "test -a/-o " t/t4102-apply-rename.sh: avoid "test -a/-o " t/t0026-eol-config.sh: avoid "test -a/-o " t/t0025-crlf-auto.sh: avoid "test -a/-o " t/lib-httpd.sh: avoid "test -a/-o " git-rebase--interactive.sh: avoid "test -a/-o " git-mergetool.sh: avoid "test -a/-o " git-bisect.sh: avoid "test -a/-o " contrib/examples/git-resolve.sh: avoid "test -a/-o " contrib/examples/git-repack.sh: avoid "test -a/-o " contrib/examples/git-merge.sh: avoid "test -a/-o " contrib/examples/git-commit.sh: avoid "test -a/-o " contrib/examples/git-clone.sh: avoid "test -a/-o " check_bindir: avoid "test -a/-o "

Merge branch 'rr/rebase-autostash-fix'

2014-06-16T17:06:57Z

* rr/rebase-autostash-fix: rebase -i: test "Nothing to do" case with autostash rebase -i: handle "Nothing to do" case with autostash

git-rebase--interactive.sh: avoid "test -a/-o "

2014-06-09T21:47:07Z

The construct is error-prone; "test" being built-in in most modern shells, the reason to avoid "test && test " spawning one extra process by using a single "test -a " no longer exists. Signed-off-by: Elia Pinto Reviewed-by: Matthieu Moy Signed-off-by: Junio C Hamano

rebase -i: handle "Nothing to do" case with autostash

2014-05-19T22:36:24Z

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

Merge branch 'km/avoid-non-function-return-in-rebase'

2014-04-21T17:42:46Z

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

rebase: avoid non-function use of "return" on FreeBSD

2014-04-17T17:13:29Z

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