Update 2021:
As I mentioned in "git stash is slow on windows", with Git for Windows 2.19 (Sept. 2018), git stash (and git rebase) are no longer script-only, but actually a binary compiled with git.exe.
Tim's answer illustrates how it is still difficult to ascertain if a rebase is in progress.
That was discussed in the mailing list, leading to patch like "status: rebase and merge can be in progress at the same time":
Since git rebase -r was introduced, that is possible.
But our machinery did not think that possible, and failed to say anything about the rebase in progress when in the middle of a merge.
There was a case of "rebase in progress" detection before that (2016), with "worktree.c: check whether branch is rebased in another worktree"
This function find_shared_symref() is used in a couple places:
- in
builtin/branch.c: it's used to detect if a branch is checked out elsewhere and refuse to delete the branch.
- in
builtin/notes.c: it's used to detect if a note is being merged in another worktree
- in
branch.c, the function die_if_checked_out() is actually used by "git checkout" and "git worktree add" to see if a branch is already checked out elsewhere and refuse the operation.
In cases 1 and 3, if a rebase is ongoing "HEAD" will be in detached mode.
find_shared_symref() fails to detect it and declares "no branch is checked out here", which is not really what we want.
Original answer: 2010
For one thing, there is a ORIG_HEAD in place during a rebase (but that is not limited to the rebase command)
But you can also look at the 2010 Git 1.7.0 git-rebase.sh script itself (which is as "internal" as you can get ;) ).
Lines like those can give you another clue:
dotest="$GIT_DIR"/rebase-merge
test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply || die "No rebase in progress?"
sabgenton comments:
- The folder
rebase-apply seems to appear with rebase,
- but a folder
rebase-merge shows up only with with rebase -i.
And hippy also comments, in 2017, that:
The coding guidelines discourage the usage of -o (see Documentation/CodingGuidelines), so the correct way now (2017, but also since 2011, Git 1.7.6) is:
(test -d ".git/rebase-merge" || test -d ".git/rebase-apply") || die "No rebase in progress?"
Jelaby suggests in the comments:
(test -d "$(git rev-parse --git-path rebase-merge)" ||
test -d "$(git rev-parse --git-path rebase-apply)" )
This correctly handles worktrees and unusual or non-standard layouts that don't have a .git directory, and also allows you to run this test from a subdir of the working directory.
That is because the git rev-parse --git-path <path>: does resolve "$GIT_DIR/<path>".
And Elizandro - SparcBR adds in the comments:
Could also redirect the error to null:
(test -d "$(git rev-parse --git-path rebase-merge)" || test -d "$(git rev-parse --git-path rebase-apply) 2>/dev/null"
Git 2.6+ (Q3 2015) will print more information during a rebase:
See commit 592e412, commit 84e6fb9 (06 Jul 2015), commit 84e6fb9 (06 Jul 2015), and commit df25e94, commit 05eb563 (30 Jun 2015) by Guillaume Pagès (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 178d2c7, 03 Aug 2015)
status: give more information during rebase -i
git status gives more information during rebase -i, about the list of commands that are done during the rebase.
It displays:
- the last two commands executed and
- the next two lines to be executed.
It also gives hints to find the whole files in .git directory.
Trying and detect the prompt won't work with Git 2.26+, as shown in commit 6d04ce7
"git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am").
(The rebase.backend configuration variable can be set to customize.)
See commit 10cdb9f, commit 2ac0d62, commit 8295ed6, commit 76340c8, commit 980b482, commit c2417d3, commit 6d04ce7, commit 52eb738, commit 8af14f0, commit be50c93, commit befb89c, commit 9a70f3d, commit 93122c9, commit 55d2b6d, commit 8a997ed, commit 7db00f0, commit e98c426, commit d48e5e2 (15 Feb 2020), and commit a9ae8fd, commit 22a69fd (16 Jan 2020) by Elijah Newren (newren).
(Merged by Junio C Hamano -- gitster -- in commit 8c22bd9, 02 Mar 2020)
git-prompt: change the prompt for interactive-based rebases
In the past, we had different prompts for different types of rebases:
REBASE: for am-based rebases
REBASE-m: for merge-based rebases
REBASE-i: for interactive-based rebases
It's not clear why this distinction was necessary or helpful; when the
prompt was added in commit e752019 ("Improve bash prompt to detect
various states like an unfinished merge", 2007-09-30, Git v1.5.5-rc0), it simply added these three different types.
Perhaps th
