Run "git pull --rebase" in interactive mode?

Question

Is it possible to run the command git pull --rebase in an interactive mode (like git rebase -i)?

Answer 1

Original answer (April 2015)

Not really, considering a git pull --rebase is not the same as a git fech + git rebase.
See what does "git pull --rebase" do?

---

Update January 2016

Git 2.8 (March 2016) will allows to have a pull --rebase interactive!

See commit 17c4ddb, commit b5496d4, commit f5eb87b (13 Jan 2016) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit f9219c0, 26 Jan 2016)}

pull: allow interactive rebase with --rebase=interactive

A couple of years ago, I found the need to collaborate on topic branches that were rebased all the time, and I really needed to see what I was rebasing when pulling, so I introduced an interactively-rebasing pull.

The way builtin pull works, this change also supports the value 'interactive' for the 'branch.<name>.rebase' config variable, which is a neat thing because users can now configure given branches for interactively-rebasing pulls without having to type out the complete --rebase=interactive option every time they pull.

---

Update August 2018, Git 2.19:

"git pull --rebase=interactive" learned "i" as a short-hand for "interactive".

See commit 46af44b (04 Aug 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit c757aa2, 17 Aug 2018)}

pull --rebase=<type>: allow single-letter abbreviations for the type

'Git for Windows' original 4aa8b8c (Teach 'git pull' to handle --rebase=interactive, 2011-10-21) had support for the very convenient abbreviation

git pull --rebase=i

which was later lost when it was ported to the builtin git pull, and it was not introduced before the patch eventually made it into Git as f5eb87b (pull: allow interactive rebase with --rebase=interactive, 2016-01-13, Git 2.8.0).

However, it is really a useful short hand for the occasional rebasing pull on branches that do not usually want to be rebased.

So let's reintroduce this convenience, at long last.

---

With Git 2.26 (Q1 2020), "git remote rename X Y" needs to adjust configuration variables (e.g. branch.<name>.remote) whose value used to be X to Y.
branch.<name>.pushRemote is now also updated.

See commit b3fd6cb (01 Feb 2020), and commit f2a2327, commit 923d4a5, commit ceff1a1, commit 1a83068, commit 88f8576 (27 Jan 2020) by Bert Wesarg (bertwesarg).
^{(Merged by Junio C Hamano -- gitster -- in commit d0038f4, 25 Feb 2020)}

pull --rebase/remote rename: document and honor single-letter abbreviations rebase types

^{Signed-off-by: Bert Wesarg}

When 46af44b07d ("pull --rebase=<type>: allow single-letter abbreviations for the type", 2018-08-04, Git v2.19.0-rc0 -- merge listed in batch #7) landed in Git, it had the side effect that not only 'pull --rebase=<type>' accepted the single-letter abbreviations but also the 'pull.rebase' and 'branch.<name>.rebase' configurations.

However, 'git remote rename' did not honor these single-letter abbreviations when reading the 'branch.*.rebase' configurations.

We now document the single-letter abbreviations and both code places share a common function to parse the values of 'git pull --rebase=*', 'pull.rebase', and 'branches.*.rebase'.

The only functional change is the handling of the branch_info::rebase value.
Before it was an unsigned enum, thus the truth value could be checked with branch_info::rebase != 0. But enum rebase_type is signed, thus the truth value must now be checked with branch_info::rebase >= REBASE_TRUE