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

Merge branch 'rr/rebase-autostash-fix' into maint

2014-06-25T18:49:31Z

The autostash mode of "git rebase -i" did not restore the dirty working tree state if the user aborted the interactive rebase by emptying the insn sheet. * rr/rebase-autostash-fix: rebase -i: test "Nothing to do" case with autostash rebase -i: handle "Nothing to do" case with autostash

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

Merge branch 'us/printf-not-echo'

2014-03-25T18:08:27Z

* us/printf-not-echo: test-lib.sh: do not "echo" caller-supplied strings rebase -i: do not "echo" random user-supplied strings

rebase -i: do not "echo" random user-supplied strings

2014-03-17T19:24:14Z

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

rebase: add the --gpg-sign option

2014-02-11T22:48:20Z

Signed-off-by: Nicolas Vigier Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

remove #!interpreter line from shell libraries

2013-11-26T22:23:56Z

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

rebase -i: respect core.abbrev

2013-09-30T21:34:50Z

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 Acked-by: Eric Sunshine Signed-off-by: Jonathan Nieder

Merge branch 'es/rebase-i-no-abbrev'

2013-09-11T22:02:29Z

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