kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Ed Maste	9b35cadc2c	rebase: update comment about FreeBSD /bin/sh 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>	9 years ago
Ben Woosley	79f43447d2	git-rebase--merge: don't include absent parent as a base 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>	9 years ago
Nguyễn Thái Ngọc Duy	b849b954d2	*.sh: avoid hardcoding $GIT_DIR/hooks/... 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>	10 years ago
brian m. carlson	95104c7e25	rebase--merge: fix --skip with two conflicts in a row 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>	11 years ago
Elia Pinto	f257482c9c	git-rebase--merge.sh: use the $( ... ) construct for command substitution 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>	11 years ago
Kyle J. McKay	9f50d32b9c	rebase: avoid non-function use of "return" on FreeBSD 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>	11 years ago
Nicolas Vigier	3ee5e54038	rebase: add the --gpg-sign option 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>	11 years ago
Jonathan Nieder	11d62145b9	remove #!interpreter line from shell libraries 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>	11 years ago
Ramkumar Ramachandra	01a1e6465f	rebase --merge: return control to caller, for housekeeping 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>	12 years ago
Martin von Zweigbergk	572a7c52bb	rebase: don't source git-sh-setup twice 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>	13 years ago
Andrew Wong	ad687b447a	rebase -m: only call "notes copy" when rewritten exists and is non-empty 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>	13 years ago
Martin von Zweigbergk	b325680930	rebase -m: don't print exit code 2 when merge fails 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>	14 years ago
Martin von Zweigbergk	84df4560ed	rebase: extract code for writing basic state 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>	14 years ago
Martin von Zweigbergk	fa99c1e1e1	rebase: extract merge code to new source file 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>	14 years ago

18 Commits (e1b3f3dd38c05187ed44939b9c67e96f0ce32d50)