summaryrefslogtreecommitdiff
path: root/git-rebase--merge.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-07-06Merge branch 'em/newer-freebsd-shells-are-fine-with-returns' into maintLibravatar Junio C Hamano1-2/+2
Comments about misbehaving FreeBSD shells have been clarified with the version number (9.x and before are broken, newer ones are OK). * em/newer-freebsd-shells-are-fine-with-returns: rebase: update comment about FreeBSD /bin/sh
2016-06-17rebase: update comment about FreeBSD /bin/shLibravatar Ed Maste1-2/+2
Commit 9f50d32 introduced a fix for FreeBSD /bin/sh misbehaviour when dot-sourcing a file containing "return" statements outside of any function, from a function in another shell script. That issue affects FreeBSD 9.x, and is not present in the /bin/sh in FreeBSD 10.3 and later. Update the comment to clarify this. The example from 9f50d32's commit message produces the expected output on FreeBSD 10.3 and -CURRENT (the upcoming 11.0): % sh script1.sh only this line should show % Signed-off-by: Ed Maste <emaste@freebsd.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-24git-rebase--merge: don't include absent parent as a baseLibravatar Ben Woosley1-1/+3
Absent this fix, attempts to rebase an orphan branch using "rebase -m" fails with: $ git rebase -m ORPHAN_TARGET_BASE First, rewinding head to replay your work on top of it... fatal: Could not parse object 'ORPHAN_ROOT_SHA^' Unknown exit code (128) from command: git-merge-recursive ORPHAN_ROOT_SHA^ -- HEAD ORPHAN_ROOT_SHA To fix, this will only include the rebase root's parent as a base if it exists, so that in cases of rebasing an orphan branch, it is a simple two-way merge. Note the default rebase behavior does not fail: $ git rebase ORPHAN_TARGET_BASE First, rewinding head to replay your work on top of it... Applying: ORPHAN_ROOT_COMMIT_MSG Using index info to reconstruct a base tree... A few tests were expecting the old behaviour to forbid rebasing such a history with "rebase -m", which now need to expect them to succeed. Signed-off-by: Ben Woosley <ben.woosley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01*.sh: avoid hardcoding $GIT_DIR/hooks/...Libravatar Nguyễn Thái Ngọc Duy1-4/+2
If $GIT_COMMON_DIR is set, it should be $GIT_COMMON_DIR/hooks/, not $GIT_DIR/hooks/. Just let rev-parse --git-path handle it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-02Merge branch 'bc/fix-rebase-merge-skip'Libravatar Junio C Hamano1-2/+3
"git rebase --skip" did not work well when it stopped due to a conflict twice in a row. * 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-06-03Merge branch 'ep/shell-command-substitution'Libravatar Junio C Hamano1-2/+2
Adjust shell scripts to use $(cmd) instead of `cmd`. * ep/shell-command-substitution: (41 commits) t5000-tar-tree.sh: use the $( ... ) construct for command substitution t4204-patch-id.sh: use the $( ... ) construct for command substitution t4119-apply-config.sh: use the $( ... ) construct for command substitution t4116-apply-reverse.sh: use the $( ... ) construct for command substitution t4057-diff-combined-paths.sh: use the $( ... ) construct for command substitution t4038-diff-combined.sh: use the $( ... ) construct for command substitution t4036-format-patch-signer-mime.sh: use the $( ... ) construct for command substitution t4014-format-patch.sh: use the $( ... ) construct for command substitution t4013-diff-various.sh: use the $( ... ) construct for command substitution t4012-diff-binary.sh: use the $( ... ) construct for command substitution t4010-diff-pathspec.sh: use the $( ... ) construct for command substitution t4006-diff-mode.sh: use the $( ... ) construct for command substitution t3910-mac-os-precompose.sh: use the $( ... ) construct for command substitution t3905-stash-include-untracked.sh: use the $( ... ) construct for command substitution t1050-large.sh: use the $( ... ) construct for command substitution t1020-subdirectory.sh: use the $( ... ) construct for command substitution t1004-read-tree-m-u-wf.sh: use the $( ... ) construct for command substitution t1003-read-tree-prefix.sh: use the $( ... ) construct for command substitution t1002-read-tree-m-u-2way.sh: use the $( ... ) construct for command substitution t1001-read-tree-m-2way.sh: use the $( ... ) construct for command substitution ...
2014-04-23git-rebase--merge.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-2/+2
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. 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-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>