git/git-rebase--common.sh, branch v2.22.2

Merge branch 'en/rebase-merge-on-sequencer'

2019-02-07T06:05:20Z

"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

git-rebase, sequencer: extend --quiet option for the interactive machinery

2018-12-28T20:49:48Z

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 Signed-off-by: Junio C Hamano

rebase: introduce --reschedule-failed-exec

2018-12-11T08:19:01Z

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 `. 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 Signed-off-by: Junio C Hamano

rebase: refactor common shell functions into their own file

2018-08-06T20:08:01Z

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--` 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 Signed-off-by: Junio C Hamano