git/git-rebase--am.sh, branch v2.8.2

rebase: return non-zero error code if format-patch fails

2015-07-08T22:36:42Z

Since e481af06 (rebase: Handle cases where format-patch fails) we notice if format-patch fails and return immediately from git-rebase--am. We save the return value with ret=$?, but then we return $?, which is usually zero in this case. Fix this by returning $ret instead. Cc: Andrew Wong Signed-off-by: Clemens Buchacher Helped-by: Jorge Nunes 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

rebase--am: use --cherry-pick instead of --ignore-if-in-upstream

2014-07-15T22:05:02Z

When using `git format-patch --ignore-if-in-upstream` we are only allowed to give a single revision range. In the next commit we will want to add an additional exclusion revision in order to handle fork points correctly, so convert `git-rebase--am` to use a symmetric difference with `--cherry-pick --right-only`. This does not change the result of the format-patch invocation, just how we spell the arguments. Signed-off-by: John Keeping 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

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

am: return control to caller, for housekeeping

2013-05-13T06:20:07Z

We only need to do these two tasks git gc --auto rm -fr "$dotest" ourselves if the script was invoked as a standalone program; when invoked with --rebasing (from git-rebase--am.sh), cascade control back to the ultimate caller git-rebase.sh to do this for us. Signed-off-by: Ramkumar Ramachandra Signed-off-by: Junio C Hamano

rebase-am: explicitly disable cover-letter

2013-04-15T03:01:07Z

If the user has a cover-letter configuration set to anything other than 'false', 'git format-patch' may generate a cover letter, which has no place in "format-patch | am" pipeline. The internal invocation of format-patch must explicitly override the configuration from the command line, just like --src-prefix and other options already do. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

rebase: Handle cases where format-patch fails

2012-10-11T18:54:49Z

'format-patch' could fail due to reasons such as out of memory. Such failures are not detected or handled, which causes rebase to incorrectly think that it completed successfully and continue with cleanup. i.e. calling move_to_original_branch Instead of using a pipe, we separate 'format-patch' and 'am' by using an intermediate file. This gurantees that we can invoke 'am' with the complete input, or not invoking 'am' at all if 'format-patch' failed. Also remove the use of '&&' at the end of the if-block, and rearrange the 'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit better and easier to read. Signed-off-by: Andrew Wong Signed-off-by: Junio C Hamano