kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Phillip Wood	da27a6fbd5	rebase --keep-empty: always use interactive rebase rebase --merge accepts --keep-empty but just ignores it, by using an implicit interactive rebase the user still gets the rename detection of a merge based rebase but with with --keep-empty support. If rebase --keep-empty without --interactive or --merge stops for the user to resolve merge conflicts then 'git rebase --continue' will fail. This is because it uses a different code path that does not create $git_dir/rebase-apply. As rebase --keep-empty was implemented using cherry-pick it has never supported the am options and now that interactive rebases support --signoff there is no loss of functionality by using an implicit interactive rebase. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Wink Saville	2f5f469bc4	rebase: update invocation of rebase dot-sourced scripts Due to historical reasons, the backend scriptlets for "git rebase" are structured a bit unusually. As originally designed, dot-sourcing them from "git rebase" was sufficient to invoke the specific backend. However, it was later discovered that some shell implementations (e.g. FreeBSD 9.x) misbehaved by continuing to execute statements following a top-level "return" rather than returning control to the next statement in "git rebase" after dot-sourcing the scriptlet. To work around this shortcoming, the whole body of git-rebase--$backend.sh was made into a shell function git_rebase__$backend, and then the very last line of the scriptlet called that function. A more normal architecture is for a dot-sourced scriptlet merely to define functions (thus acting as a function library), and for those functions to be called by the script doing the dot-sourcing. Migrate to this arrangement by moving the git_rebase__$backend call from the end of a scriptlet into "git rebase" itself. While at it, remove the large comment block from each scriptlet explaining this historic anomaly since it serves no purpose under the new normalized architecture in which a scriptlet is merely a function library. Signed-off-by: Wink Saville <wink@saville.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Nguyễn Thái Ngọc Duy	66335298a4	rebase: add --show-current-patch It is useful to see the full patch while resolving conflicts in a rebase. The only way to do it now is less .git/rebase-*/patch which could turn out to be a lot longer to type if you are in a linked worktree, or not at top-dir. On top of that, an ordinary user should not need to peek into .git directory. The new option is provided to examine the patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Genki Sky	a6c612b528	rebase: add --allow-empty-message option This option allows commits with empty commit messages to be rebased, matching the same option in git-commit and git-cherry-pick. While empty log messages are frowned upon, sometimes one finds them in older repositories (e.g. translated from another VCS [0]), or have other reasons for desiring them. The option is available in git-commit and git-cherry-pick, so it is natural to make other git tools play nicely with them. Adding this as an option allows the default to be "give the user a chance to fix", while not interrupting the user's workflow otherwise [1]. [0]: https://stackoverflow.com/q/8542304 [1]: https://public-inbox.org/git/7vd33afqjh.fsf@alter.siamese.dyndns.org/ To implement this, add a new --allow-empty-message flag. Then propagate it to all calls of 'git commit', 'git cherry-pick', and 'git rebase--helper' within the rebase scripts. Signed-off-by: Genki Sky <sky@genki.is> Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Eric Wong	ae3b2b04bb	rebase: use mboxrd format to avoid split errors The mboxrd format allows the use of embedded "From " lines in commit messages without being misinterpreted by mailsplit Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Kevin Willford	9eaa858eb9	rebase: turn on progress option by default for format-patch Pass the "--progress" option to format-patch when the standard error stream is connected to the terminal and "--quiet" is not given. Signed-off-by: Kevin Willford <kewillf@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Phillip Wood	5fb415b57f	rebase: honor --rerere-autoupdate Rebase accepts '--rerere-autoupdate' as an option but only honors it if '-m' is also given. Fix it for a non-interactive rebase by passing on the option to 'git am' and 'git cherry-pick'. Rework the tests so that they can be used for each rebase flavor and extend them. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
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
Clemens Buchacher	60d708b220	rebase: return non-zero error code if format-patch fails 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 <andrew.kw.w@gmail.com> Signed-off-by: Clemens Buchacher <clemens.buchacher@intel.com> Helped-by: Jorge Nunes <jorge.nunes@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
John Keeping	1e0dacdbdb	rebase: omit patch-identical commits with --fork-point 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 <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
John Keeping	b6266dc88b	rebase--am: use --cherry-pick instead of --ignore-if-in-upstream 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 <john@keeping.me.uk> 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	a1549e1049	am: return control to caller, for housekeeping 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 <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Felipe Contreras	0597ffa5ec	rebase-am: explicitly disable cover-letter 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 <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Andrew Wong	e481af06be	rebase: Handle cases where format-patch fails '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 <andrew.kw.w@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
Neil Horman	90e1818f9a	git-rebase: add keep_empty flag Add a command line switch to git-rebase to allow a user the ability to specify that they want to keep any commits in a series that are empty. When git-rebase's type is am, then this option will automatically keep any commit that has a tree object identical to its parent. This patch changes the default behavior of interactive rebases as well. With this patch, git-rebase -i will produce a revision set passed to git-revision-editor, in which empty commits are commented out. Empty commits may be kept manually by uncommenting them. If the new --keep-empty option is used in an interactive rebase the empty commits will automatically all be uncommented in the editor. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Martin von Zweigbergk	c5e610be50	git-rebase--am: remove unnecessary --3way option Since `22db240` (git-am: propagate --3way options as well, 2008-12-04), the --3way has been propageted across failure, so it is since pointless to pass it to git-am when resuming. 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	46df82d5fa	rebase: extract am code to new source file Extract the code for am-based rebase to git-rebase--am.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

26 Commits (6373cb598e1a4e0340583ad75d5abba01ff79774)