How to know if there is a git rebase in progress?

git git-rebase

30,872

Solution 1

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 there was a useful purpose back then, but there have been some changes:

The merge backend was deleted after being implemented on top of the interactive backend, causing the prompt for merge-based rebases to change from REBASE-m to REBASE-i.

The interactive backend is used for multiple different types of non-interactive rebases, so the "-i" part of the prompt doesn't really mean what it used to.

Rebase backends have gained more abilities and have a great deal of overlap, sometimes making it hard to distinguish them.

Behavioral differences between the backends have also been ironed out.

We want to change the default backend from am to interactive, which means people would get "REBASE-i" by default if we didn't change the prompt, and only if they specified --am or --whitespace or -C would they get the "REBASE" prompt.

In the future, we plan to have "--whitespace", "-C", and even "--am" run the interactive backend once it can handle everything the am-backend can.

For all these reasons, make the prompt for any type of rebase just be "REBASE".

Since Git 2.17 (March 2018), you also have:

git rebase --show-current-patch

It shows the content of .git/REBASE_HEAD during an interactive rebase which can be paused during conflict.

Solution 2

You can also check how such detection is done in __git_ps1 function in contrib/completion/git-prompt.sh, which can be used for git-aware bash prompt:

                if [ -f "$g/rebase-merge/interactive" ]; then
                        r="|REBASE-i"
                        b="$(cat "$g/rebase-merge/head-name")"
                elif [ -d "$g/rebase-merge" ]; then
                        r="|REBASE-m"
                        b="$(cat "$g/rebase-merge/head-name")"
                else
                        if [ -d "$g/rebase-apply" ]; then
                                if [ -f "$g/rebase-apply/rebasing" ]; then
                                        r="|REBASE"
                                elif [ -f "$g/rebase-apply/applying" ]; then
                                        r="|AM"
                                else
                                        r="|AM/REBASE"
                                fi
                        fi
                fi

Solution 3

If there’s an interactive rebase in progress, this will tell you where you are in the process:

$ cat .git/rebase-merge/done 
pick 786139e lrg
edit 668b8a6 ktio
$

Right now I’m editing the “ktio” patch in an interactive rebase.

If there’s no rebase going on, it will look like this:

$ cat .git/rebase-merge/done 
cat: .git/rebase-merge/done: No such file or directory
$

Solution 4

From a bash command line:

ls `git rev-parse --git-dir` | grep rebase

That will return exit code 0 (success) if there is a rebase folder, and it will output the rebase folder to STDOUT. If you are not in the middle of a rebase, then it will output nothing and return non-0 exit code. So you could even do something like this:

ls `git rev-parse --git-dir` | grep rebase || echo no rebase

Solution 5

There are some bad answers here. git doesn't really have a specification for how it should work so the only answer is "how does git do it?". The code is here:

int wt_status_check_rebase(const struct worktree *wt,
               struct wt_status_state *state)
{
    struct stat st;

    if (!stat(worktree_git_path(wt, "rebase-apply"), &st)) {
        if (!stat(worktree_git_path(wt, "rebase-apply/applying"), &st)) {
            state->am_in_progress = 1;
            if (!stat(worktree_git_path(wt, "rebase-apply/patch"), &st) && !st.st_size)
                state->am_empty_patch = 1;
        } else {
            state->rebase_in_progress = 1;
            state->branch = get_branch(wt, "rebase-apply/head-name");
            state->onto = get_branch(wt, "rebase-apply/onto");
        }
    } else if (!stat(worktree_git_path(wt, "rebase-merge"), &st)) {
        if (!stat(worktree_git_path(wt, "rebase-merge/interactive"), &st))
            state->rebase_interactive_in_progress = 1;
        else
            state->rebase_in_progress = 1;
        state->branch = get_branch(wt, "rebase-merge/head-name");
        state->onto = get_branch(wt, "rebase-merge/onto");
    } else
        return 0;
    return 1;
}

It basically checks if these few files/directories exist (note !stat() means "does the file exist"). am is git am which is for applying patches from a mailbox which I doubt anyone except the Linux developers use.

rebase_in_progress: .git/rebase-apply && !.git/rebase-apply/applying || .git/rebase-merge && !.git/rebase-merge/interactive
interactive_rebase_in_progress: .git/rebase-merge && .git/rebase-merge/interactive
am_in_progress: .git/rebase-apply && .git/rebase-apply/applying

I guess if you want to know if any kind of rebase/am is happening just check if .git/rebase-apply or .git/rebase-merge exist.

View more solutions

30,872

Author by

Olivier Verdier

Updated on July 05, 2022

Comments

Olivier Verdier about 2 years

When I start a git rebase -i, I can issue commands like git rebase --continue, or git rebase --abort. Those commands only work if a rebase is in progress.

How can I know if there is a rebase in progress?

(I would greatly appreciate some details on how rebase works internally; what does git do to a repo that gives it the "rebase in progress" status,?)
cmcginty over 13 years

shouldn't git-status tell you this?
Olivier Verdier over 13 years

As of git version 1.7.3.1, git status doesn't say anything about the rebase status.
Rory O'Kane almost 12 years

However, EasyGit’s eg status does tell you.
Rory O'Kane almost 12 years

Interpreting the git-rebase.sh code in this answer, Git knows there is a rebase in progress if, inside the .git folder at the root of the repo, either of the directories rebase-merge or rebase-apply exist.
VonC almost 12 years

@RoryO'Kane that sounds about right, and +1 on your answer with EasyGit.
greg0ire over 10 years

Do you really need the dotest variable ?
VonC over 10 years

@greg0ire probably not, it was just how the script was initially written.
greg0ire over 10 years

thanks, I was just checking if I was missing something, as I intend to reuse this elsewhere...
hIpPy about 7 years

The master link for git-rebase.sh now does not have the quoted code. VonC, please use this link which is tag: v1.7.0-rc1. The coding guidelines discourage the usage of -o (see github.com/git/git/blob/…) so the correct way now is (test -d ".git/rebase-merge" || test -d ".git/rebase-apply") || die "No rebase in progress?".
VonC about 7 years

@hIpPy Thank you. I have updated this 7 years-old question accordingly, adding a link to the exact commit which made that change.
Jelaby over 6 years

In Git 2.7 and maybe earlier, you can use something like (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.
VonC over 6 years

@Jelaby Thank you, good point. I have included your comment in the answer for more visibility.
Elizandro - SparcBR over 4 years

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"
VonC over 4 years

@Elizandro-SparcBR Interesting, thank you. I have included your comment in the answer for more visibility.
Elizandro - SparcBR over 4 years

How about .git/REBASE_HEAD ? It contains a hash. Could that also be reliable? It's similar to MERGE_HEAD, in the case of a git merge.
VonC over 4 years

@Elizandro-SparcBR It is a marker, to indicate at what commit the rebase is at in case of conflict. I would therefore use git rebase --show-current-patch (git-scm.com/docs/git-rebase#Documentation/…)
CLOVIS over 4 years

This is broken: if you have a dirty file that contains 'rebasing', it will print that you are rebasing even though you aren't.
VonC almost 4 years

True, but not applicable for a script: parsing/grepping the git status output would not be a good practice, as commented in stackoverflow.com/questions/3921409/…
VonC about 3 years

Good points. Upvoted. I have referenced your answer in my edited/revised answer.
Ted almost 3 years

Good one. Just add --porcelain or --porcelain=v2 to make it more suitable for automated scripts.
Moberg over 2 years

How should this be modified if .git is a file with a path to the actual git folder?
Moberg over 2 years

I don't understand this answer. Is the 2021 update providing some new command or just adding additional information about git internals? Is (test -d "$(git rev-parse --git-path rebase-merge)" || \ test -d "$(git rev-parse --git-path rebase-apply)" ) the recommended way?
VonC over 2 years

test -d ... was the old answer. The 2021 update is to point out the answer is not as easy as using git rev-parse output. Tim's answer illustrates that.
Timmmm over 2 years

If you're in a worktree and .git is a file then you need to parse the file (e.g. it might contain gitdir: /path/to/repo/.git/worktrees/worktreename) and then check for /path/to/repo/.git/worktrees/worktreename/rebase-apply etc.