REBASE_HEAD still exists after success end rebase

REBASE_HEAD still exists after success end rebase

[Long 76]

Hi,
My configuration:
OS Kubuntu 24.04
Git version: 2.54.0 from ppa:git-core/ppa

.gitconfig
[merge]
     guitool = meld
     tool = meld
[core]
     editor = code -w
     autocrlf = input
     quotePath = false
     eol = lf

[global]
[diff]
     tool = meld
[gui]
     editor = code
[fetch]
     prune = true
[mergetool]
     keepBackup = false

How to reproduce:
1) Made repo
# Init repo with README.md
git init
echo -e '# Git rebase bug\n\n```\ngit rebase master\ngit mergetool\ngit 
rebase --continue\ngit rev-parse REBASE_HEAD\n```' > README.md
git add README.md
git commit -m "docs: add README.md"

# Add feature branch
git branch feature_branch

# Add files in separate commits
echo -e "Text 1 line\nText 2 line\nText 3 line\nText 4 line\nText 5 
line" > Text1.txt
git add Text1.txt
git commit -m "feat: add Text1.txt"

echo -e "Text 1 line\nText 2 line\nText 3 line\nText 4 line\nText 5 
line" > Text2.txt
git add Text2.txt
git commit -m "feat: add Text2.txt"

echo -e "Text 1 line\nText 2 line\nText 3 line\nText 4 line\nText 5 
line" > Text3.txt
git add Text3.txt
git commit -m "feat: add Text3.txt"

# Do the same in feature branch and one more in one commit
git checkout feature_branch
echo -e "Texts 1 line\nTexts 2 line\nTexts 3 line\nText 4 line\nTexts 5 
line" > Text1.txt
git add Text1.txt

echo -e "Text 1 line\nText 2 line\nText 3 line\nText 4 line\nText 5 
line" > Text2.txt
git add Text2.txt

echo -e "Texts 1 line\nTexts 2 line\nTexts 3 line\nText 4 line\nTexts 5 
line" > Text3.txt
git add Text3.txt

echo -e "Texts 1 line\nTexts 2 line\nText 3 line\nTexts 4 line\nText 5 
line" > Text4.txt
git add Text4.txt
git commit -m "feat: add all files"
2) Call — git rebase master
3) Call — git mergetool
4) Call — git rebase --continue
5) Call — git rev-parse REBASE_HEAD
Last command return value and .git/REBASE_HEAD exists.
In other words REBASE_HEAD exists if ogirinal commit in new branch 
modified and need call git push --force to send it to server. Please fix 
it, thanks!

--
Long76

Re: REBASE_HEAD still exists after success end rebase

[Matt Hunter]

On Tue Jul 28, 2026 at 4:26 AM EDT, Long 76 wrote:
>
> In other words REBASE_HEAD exists if ogirinal commit in new branch 
> modified and need call git push --force to send it to server. Please fix 
> it, thanks!

I ran into this not that long ago too, while working on a script.  It
looked like this behavior depended on how the _last_ item in the rebase
todo list was handled.  I found if the last action was a squash or edit
(I don't think reword did this), then REBASE_HEAD was left behind.

Also, if rebase stops on a break command, then REBASE_HEAD will be
missing, even though a rebase is still in-progress.

I made a very short-lived effort to look into why this "bug" was
happening.  I say "bug" in quotes, because I'm not even sure if it is
even problematic behavior.

I solved my need at the time (detecting a rebase in progress) by
checking for the existence of either of the 'rebase-merge' or
'rebase-apply' directories in $GIT_DIR.
>
> --
> Long76

Re: REBASE_HEAD still exists after success end rebase

[Phillip Wood]

On 28/07/2026 10:39, Matt Hunter wrote:
> On Tue Jul 28, 2026 at 4:26 AM EDT, Long 76 wrote:
>>
>> In other words REBASE_HEAD exists if ogirinal commit in new branch
>> modified and need call git push --force to send it to server. Please fix
>> it, thanks!

The need for "--force" when pushing is due to you having rebased the 
branch, it is unrelated to the existence of REBASE_HEAD (other than the 
fact that it exists indicates you have rebased). Rebasing rewrites the 
history which means that the remote cannot fast-forward when you push. 
Rather than using "--force" I'd recommend "--force-with-lease 
--force-if-includes" instead (see the "git push" man page for more details).

> I ran into this not that long ago too, while working on a script.  It
> looked like this behavior depended on how the _last_ item in the rebase
> todo list was handled.  I found if the last action was a squash or edit
> (I don't think reword did this), then REBASE_HEAD was left behind.
> 
> Also, if rebase stops on a break command, then REBASE_HEAD will be
> missing, even though a rebase is still in-progress.
> 
> I made a very short-lived effort to look into why this "bug" was
> happening.  I say "bug" in quotes, because I'm not even sure if it is
> even problematic behavior.

I think leaving REBASE_HEAD behind after a rebase is a bug, albeit not a 
very serious one. Looking at the code we delete it before processing 
each command, but do not clean it up after the last command.

> I solved my need at the time (detecting a rebase in progress) by
> checking for the existence of either of the 'rebase-merge' or
> 'rebase-apply' directories in $GIT_DIR.

That's the best way to detect if a rebase is in progress - REBASE_HEAD 
only exists when there are conflicts, or the editor is opened for the 
user to reword a commit. It does not exist when the user is editing the 
todo list at the start of a rebase; when stopping for conflicts after a 
"merge parent" command without "-C"; when stopping for a break or failed 
exec command.

Thanks

Phillip

Re: REBASE_HEAD still exists after success end rebase

[Long 76]

> The need for "--force" when pushing is due to you having rebased the 
> branch, it is unrelated to the existence of REBASE_HEAD (other than the 
> fact that it exists indicates you have rebased). Rebasing rewrites the 
> history which means that the remote cannot fast-forward when you push. 
> Rather than using "--force" I'd recommend "--force-with-lease --force- 
> if-includes" instead (see the "git push" man page for more details).

I know it, commit don't the same that was before rebase - because of the 
conflict, it had to be changed.

Re: REBASE_HEAD still exists after success end rebase

[Long 76]

> I made a very short-lived effort to look into why this "bug" was
> happening.  I say "bug" in quotes, because I'm not even sure if it is
> even problematic behavior.

I think this is a bug because git create similar HEADs if you made merge 
or cherry-pick. I don't have problems with them.

Plus by git rebase docs on official site flag '--show-current-patch':
---
Show the current patch in an interactive rebase or when rebase is 
stopped because of conflicts. This is the equivalent of git show 
REBASE_HEAD.
---
For me it means that return patch only if rebase in progress - not 
aborted/not complete/have conflicts

> I solved my need at the time (detecting a rebase in progress) by
> checking for the existence of either of the 'rebase-merge' or
> 'rebase-apply' directories in $GIT_DIR.

Thanks for advice! I don't knew it.

Re: REBASE_HEAD still exists after success end rebase

[Long 76]

+ phillip.wood@dunelm.org.uk

28.07.2026 18:27, Long 76 пишет:
>> I made a very short-lived effort to look into why this "bug" was
>> happening.  I say "bug" in quotes, because I'm not even sure if it is
>> even problematic behavior.
> 
> I think this is a bug because git create similar HEADs if you made merge 
> or cherry-pick. I don't have problems with them.
> 
> Plus by git rebase docs on official site flag '--show-current-patch':
> ---
> Show the current patch in an interactive rebase or when rebase is 
> stopped because of conflicts. This is the equivalent of git show 
> REBASE_HEAD.
> ---
> For me it means that return patch only if rebase in progress - not 
> aborted/not complete/have conflicts
> 
>> I solved my need at the time (detecting a rebase in progress) by
>> checking for the existence of either of the 'rebase-merge' or
>> 'rebase-apply' directories in $GIT_DIR.
> 
> Thanks for advice! I don't knew it.