summaryrefslogtreecommitdiff
path: root/git-rebase--merge.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-07-16Merge branch 'bc/fix-rebase-merge-skip' into maintLibravatar Junio C Hamano1-2/+3
During "git rebase --merge", a conflicted patch could not be skipped with "--skip" if the next one also conflicted. * bc/fix-rebase-merge-skip: rebase--merge: fix --skip with two conflicts in a row
2014-06-16rebase--merge: fix --skip with two conflicts in a rowLibravatar brian m. carlson1-2/+3
If git rebase --merge encountered a conflict, --skip would not work if the next commit also conflicted. The msgnum file would never be updated with the new patch number, so no patch would actually be skipped, resulting in an inescapable loop. Update the msgnum file's value as the first thing in call_merge. This also avoids an "Already applied" message when skipping a commit. There is no visible change for the other contexts in which call_merge is invoked, as the msgnum file's value remains unchanged in those situations. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> 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-02-11rebase: add the --gpg-sign optionLibravatar Nicolas Vigier1-1/+1
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-1/+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-05-12rebase --merge: return control to caller, for housekeepingLibravatar Ramkumar Ramachandra1-3/+2
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>
2012-06-26rebase: don't source git-sh-setup twiceLibravatar Martin von Zweigbergk1-2/+0
The git-sh-setup script is already sourced in git-rebase.sh before calling into git-rebase--(am|interactive|merge).sh. There are no other callers of these scripts. It is therefore unnecessary to source git-sh-setup again in them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-26rebase -m: only call "notes copy" when rewritten exists and is non-emptyLibravatar Andrew Wong1-4/+7
This prevents a shell error complaining rebase-merge/rewritten doesn't exist. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-10rebase -m: don't print exit code 2 when merge failsLibravatar Martin von Zweigbergk1-1/+1
When the merge strategy fails, a message suggesting the user to try another strategy is displayed. Remove the "$rv" (which is always equal to "2" in this case) from that message. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-10rebase: extract code for writing basic stateLibravatar Martin von Zweigbergk1-4/+1
Extract the code for writing the state to rebase-apply/ or rebase-merge/ when a rebase is initiated. This will make it easier to later make both interactive and non-interactive rebase remember the options used. Note that non-interactive rebase stores the sha1 of the original head in a file called orig-head, while interactive rebase stores it in a file called head. Change this by writing to orig-head in both cases. When reading, try to read from orig-head. If that fails, read from head instead. This protects users who upgraded git while they had an ongoing interactive rebase, while still making it possible to remove the code that reads from head at some point in the future. Helped-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-10rebase: extract merge code to new source fileLibravatar Martin von Zweigbergk1-0/+154
Extract the code for merge-based rebase to git-rebase--merge.sh. Suggested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>