summaryrefslogtreecommitdiff
path: root/git-legacy-rebase.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-02-08Merge branch 'js/rebase-i-redo-exec-fix'Libravatar Junio C Hamano1-6/+0
For "rebase -i --reschedule-failed-exec", we do not want the "-y" shortcut after all. * js/rebase-i-redo-exec-fix: Revert "rebase: introduce a shortcut for --reschedule-failed-exec"
2019-02-06Merge branch 'en/rebase-merge-on-sequencer'Libravatar Junio C Hamano1-35/+30
"git rebase --merge" as been reimplemented by reusing the internal machinery used for "git rebase -i". * en/rebase-merge-on-sequencer: rebase: implement --merge via the interactive machinery rebase: define linearization ordering and enforce it git-legacy-rebase: simplify unnecessary triply-nested if git-rebase, sequencer: extend --quiet option for the interactive machinery am, rebase--merge: do not overlook --skip'ed commits with post-rewrite t5407: add a test demonstrating how interactive handles --skip differently rebase: fix incompatible options error message rebase: make builtin and legacy script error messages the same
2019-02-06Revert "rebase: introduce a shortcut for --reschedule-failed-exec"Libravatar Johannes Schindelin1-6/+0
This patch was contributed only as a tentative "we could introduce a convenient short option if we do not want to change the default behavior in the long run" patch, opening the discussion whether other people agree with deprecating the current behavior in favor of the rescheduling behavior. But the consensus on the Git mailing list was that it would make sense to show a warning in the near future, and flip the default rebase.rescheduleFailedExec to reschedule failed `exec` commands by default. See e.g. <CAGZ79kZL5CRqCDRb6B-EedUm8Z_i4JuSF2=UtwwdRXMitrrOBw@mail.gmail.com> So let's back out that patch that added the `-y` short option that we agreed was not necessary or desirable. This reverts commit 81ef8ee75d5f348d3c71ff633d13d302124e1a5e. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'pw/no-editor-in-rebase-i-implicit'Libravatar Junio C Hamano1-2/+2
When GIT_SEQUENCE_EDITOR is set, the command was incorrectly started when modes of "git rebase" that implicitly uses the machinery for the interactive rebase are run, which has been corrected. * pw/no-editor-in-rebase-i-implicit: implicit interactive rebase: don't run sequence editor
2019-01-28implicit interactive rebase: don't run sequence editorLibravatar Phillip Wood1-2/+2
If GIT_SEQUENCE_EDITOR is set then rebase runs it when executing implicit interactive rebases which are supposed to appear non-interactive to the user. Fix this by setting GIT_SEQUENCE_EDITOR=: rather than GIT_EDITOR=:. A couple of tests relied on the old behavior so they are updated to work with the new regime. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07rebase: implement --merge via the interactive machineryLibravatar Elijah Newren1-22/+21
As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28git-legacy-rebase: simplify unnecessary triply-nested ifLibravatar Elijah Newren1-12/+8
The git-legacy-rebase.sh script previously had code of the form: if git_am_opt: if interactive: if incompatible_opts: show_error_about_interactive_and_am_incompatibilities if rebase-merge: if incompatible_opts show_error_about_merge_and_am_incompatibilities which was a triply nested if. However, the first conditional (git_am_opt) and third (incompatible_opts) were somewhat redundant: the latter condition was a strict subset of the former. Simplify this by moving the innermost conditional to the outside, allowing us to remove the test on git_am_opt entirely and giving us the following form: if incompatible_opts: if interactive: show_error_about_interactive_and_am_incompatibilities if rebase-merge: show_error_about_merge_and_am_incompatibilities Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28git-rebase, sequencer: extend --quiet option for the interactive machineryLibravatar Elijah Newren1-1/+1
While 'quiet' and 'interactive' may sound like antonyms, the interactive machinery actually has logic that implements several interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges) which won't pop up an editor. The rewrite of interactive rebase in C added a quiet option, though it only turns stats off. Since we want to make the interactive machinery also take over for git-rebase--merge, it should fully implement the --quiet option. git-rebase--interactive was already somewhat quieter than git-rebase--merge and git-rebase--am, possibly because cherry-pick has just traditionally been quieter. As such, we only drop a few informational messages -- "Rebasing (n/m)" and "Successfully rebased..." Also, for simplicity, remove the differences in how quiet and verbose options were recorded. Having one be signalled by the presence of a "verbose" file in the state_dir, while the other was signalled by the contents of a "quiet" file was just weirdly inconsistent. (This inconsistency pre-dated the rewrite into C.) Make them consistent by having them both key off the presence of the file. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28rebase: fix incompatible options error messageLibravatar Elijah Newren1-2/+2
In commit f57696802c30 ("rebase: really just passthru the `git am` options", 2018-11-14), the handling of `git am` options was simplified dramatically (and an option parsing bug was fixed), but it introduced a small regression in the error message shown when options only understood by separate backends were used: $ git rebase --keep --ignore-whitespace fatal: cannot combine interactive options (--interactive, --exec, --rebase-merges, --preserve-merges, --keep-empty, --root + --onto) with am options (.git/rebase-apply/applying) $ git rebase --merge --ignore-whitespace fatal: cannot combine merge options (--merge, --strategy, --strategy-option) with am options (.git/rebase-apply/applying) Note that in both cases, the list of "am options" is ".git/rebase-apply/applying", which makes no sense. Since the lists of backend-specific options is documented pretty thoroughly in the rebase man page (in the "Incompatible Options" section, with multiple links throughout the document), and since I expect this list to change over time, just simplify the error message. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28rebase: make builtin and legacy script error messages the sameLibravatar Elijah Newren1-6/+6
The conversion of the script version of rebase took messages that were prefixed with "error:" and passed them along to die(), which adds a "fatal:" prefix, thus resulting in messages of the form: fatal: error: cannot combine... which seems redundant. Remove the "error:" prefix from the builtin version of rebase, and change the prefix from "error:" to "fatal:" in the legacy script to match. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11rebase: introduce a shortcut for --reschedule-failed-execLibravatar Johannes Schindelin1-0/+6
It is a bit cumbersome to write out the `--reschedule-failed-exec` option before `-x <cmd>` all the time; let's introduce a convenient option to do both at the same time: `-y <cmd>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11rebase: add a config option to default to --reschedule-failed-execLibravatar Johannes Schindelin1-0/+2
It would be cumbersome to type out that option all the time, so let's offer the convenience of a config setting: rebase.rescheduleFailedExec. Besides, this opens the door to changing the default in a future version of Git: it does make some sense to reschedule failed `exec` commands by default (and if we could go back in time when the `exec` command was invented, we probably would change that default right from the start). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11rebase: introduce --reschedule-failed-execLibravatar Johannes Schindelin1-1/+15
A common use case for the `--exec` option is to verify that each commit in a topic branch compiles cleanly, via `git rebase -x make <base>`. However, when an `exec` in such a rebase fails, it is not re-scheduled, which in this instance is not particularly helpful. Let's offer a flag to reschedule failed `exec` commands. Based on an idea by Paul Morelle. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-30rebase --stat: fix when rebasing to an unrelated historyLibravatar Johannes Schindelin1-2/+8
When rebasing to a commit history that has no common commits with the current branch, there is no merge base. In diffstat mode, this means that we cannot compare to the merge base, but we have to compare to the empty tree instead. Also, if running in verbose diffstat mode, we should not output Changes from <merge-base> to <onto> as that does not make sense without any merge base. Note: neither scripted nor built-in versoin of `git rebase` were prepared for this situation well. We use this opportunity not only to fix the bug(s), but also to make both versions' output consistent in this instance. And add a regression test to keep this working in all eternity. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-21legacy-rebase: backport -C<n> and --whitespace=<option> checksLibravatar Johannes Schindelin1-0/+8
Since 04519d720114 (rebase: validate -C<n> and --whitespace=<mode> parameters early, 2018-11-14), the built-in rebase validates the -C and --whitespace arguments early. As this commit also introduced a regression test for this, and as a later commit introduced the GIT_TEST_REBASE_USE_BUILTIN mode to run tests, we now have a "regression" in the scripted version of `git rebase` on our hands. Backport the validation to fix this. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02Merge branch 'ag/rebase-i-in-c'Libravatar Junio C Hamano1-5/+42
Rewrite of the remaining "rebase -i" machinery in C. * ag/rebase-i-in-c: rebase -i: move rebase--helper modes to rebase--interactive rebase -i: remove git-rebase--interactive.sh rebase--interactive2: rewrite the submodes of interactive rebase in C rebase -i: implement the main part of interactive rebase as a builtin rebase -i: rewrite init_basic_state() in C rebase -i: rewrite write_basic_state() in C rebase -i: rewrite the rest of init_revisions_and_shortrevisions() in C rebase -i: implement the logic to initialize $revisions in C rebase -i: remove unused modes and functions rebase -i: rewrite complete_action() in C t3404: todo list with commented-out commands only aborts sequencer: change the way skip_unnecessary_picks() returns its result sequencer: refactor append_todo_help() to write its message to a buffer rebase -i: rewrite checkout_onto() in C rebase -i: rewrite setup_reflog_action() in C sequencer: add a new function to silence a command, except if it fails rebase -i: rewrite the edit-todo functionality in C editor: add a function to launch the sequence editor rebase -i: rewrite append_todo_help() in C sequencer: make three functions and an enum from sequencer.c public
2018-11-02Merge branch 'pk/rebase-in-c'Libravatar Junio C Hamano1-0/+708
Rewrite of the "rebase" machinery in C. * pk/rebase-in-c: builtin/rebase: support running "git rebase <upstream>" rebase: refactor common shell functions into their own file rebase: start implementing it as a builtin
2018-08-06rebase: refactor common shell functions into their own fileLibravatar Pratik Karki1-67/+2
The functions present in `git-legacy-rebase.sh` are used by the rebase backends as they are implemented as shell script functions in the `git-rebase--<backend>` files. To make the `builtin/rebase.c` work, we have to provide support via a Unix shell script snippet that uses these functions and so, we want to use the rebase backends *directly* from the builtin rebase without going through `git-legacy-rebase.sh`. This commit extracts the functions to a separate file, `git-rebase--common`, that will be read by `git-legacy-rebase.sh` and by the shell script snippets which will be used extensively in the following commits. Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-06rebase: start implementing it as a builtinLibravatar Pratik Karki1-0/+773
This commit imitates the strategy that was used to convert the difftool to a builtin. We start by renaming the shell script `git-rebase.sh` to `git-legacy-rebase.sh` and introduce a `builtin/rebase.c` that simply executes the shell script version, unless the config setting `rebase.useBuiltin` is set to `true`. The motivation behind this is to rewrite all the functionality of the shell script version in the aforementioned `rebase.c`, one by one and be able to conveniently test new features by configuring `rebase.useBuiltin`. In the original difftool conversion, if sane_execvp() that attempts to run the legacy scripted version returned with non-negative status, the command silently exited without doing anything with success, but sane_execvp() should not return with non-negative status in the first place, so we use die() to notice such an abnormal case. We intentionally avoid reading the config directly to avoid messing up the GIT_* environment variables when we need to fall back to exec()ing the shell script. The test of builtin rebase can be done by `git -c rebase.useBuiltin=true rebase ...` Signed-off-by: Pratik Karki <predatoramigo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>