bug report: I was allowed to "git checkout -b" while mid-rebase

bug report: I was allowed to "git checkout -b" while mid-rebase

[Grant Birchmeier]

[-- Attachment #1.1: Type: text/plain, Size: 1641 bytes --]

Hello.  I've attached my git-bugreport, but I'll copy/paste the salient
parts here.  Thanks.  Let me know if I can provide anything else.

*What did you do before the bug happened? (Steps to reproduce your issue)*

I was rebasing a branch "ilogger" on my master branch.  While this rebase
was still open, I accidentally ran `git checkout -b net5` (I meant to run
it in a different console)... and it proceeded to switch me to the new
branch even though the the rebase was still in progress.

*What did you expect to happen? (Expected behavior)*

I would expect an error message and a refusal to execute the `git checkout
-b` command.

*What happened instead? (Actual behavior)*

It created a new branch "net5" off of my "ilogger" mid-rebase branch, and
changed me to branch "net5".  I cannot change back to "ilogger" ("error:
you need to resolve your current index first"), and it appears I will need
to finish my rebase on "net5".  Even after I do that, I'm not sure what
state "ilogger" will be in.

*What's different between what you expected and what actually happened?*

I think the proper bahavior is for the "git checkout -b" command to fail
when the current branch is mid-rebase, just like it does when you run `git
checkout` without the `-b`.


-- 
<https://www.connamara.com>

Grant Birchmeier

Director of Engineering, Connamara

gbirchmeier@connamara.com

-- 
This email, along with any attachments, is confidential. If you believe you 
received this message in error, please contact the sender immediately and 
delete all copies of the message. Thank you from Connamara Systems, LLC.

[-- Attachment #1.2: Type: text/html, Size: 3863 bytes --]

[-- Attachment #2: git-bugreport-2025-06-18-1843.txt --]
[-- Type: text/plain, Size: 1822 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

I was rebasing a branch "ilogger" on my master branch.  While this rebase was still open, I accidentally ran `git checkout -b net5` (I meant to run it in a different console)... and it proceeded to switch me to the new branch even though the the rebase was still in progress.

What did you expect to happen? (Expected behavior)

I would expect an error message and a refusal to execute the `git checkout -b` command.

What happened instead? (Actual behavior)

It created a new branch "net5" off of my "ilogger" mid-rebase branch, and changed me to branch "net5".  I cannot change back to "ilogger" ("error: you need to resolve your current index first"), and it appears I will need to finish my rebase on "net5".  Even after I do that, I'm not sure what state "ilogger" will be in.

What's different between what you expected and what actually happened?

I think the proper bahavior is for the "git checkout -b" command to fail when the current branch is mid-rebase, just like it does when you run `git checkout` without the `-b`.

Anything else you want to add:

(nothing)

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.45.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:26 PDT 2025; root:xnu-11417.121.6~2/RELEASE_X86_64 x86_64
compiler info: clang: 15.0.0 (clang-1500.3.9.4)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: bug report: I was allowed to "git checkout -b" while mid-rebase

[Jacob Keller]

On 6/18/2025 5:12 PM, Grant Birchmeier wrote:
> Hello.  I've attached my git-bugreport, but I'll copy/paste the salient
> parts here.  Thanks.  Let me know if I can provide anything else.
> 
> *What did you do before the bug happened? (Steps to reproduce your issue)*
> 
> I was rebasing a branch "ilogger" on my master branch.  While this rebase
> was still open, I accidentally ran `git checkout -b net5` (I meant to run
> it in a different console)... and it proceeded to switch me to the new
> branch even though the the rebase was still in progress.
> 
> *What did you expect to happen? (Expected behavior)*
> 
> I would expect an error message and a refusal to execute the `git checkout
> -b` command.
> 
> *What happened instead? (Actual behavior)*
> 
> It created a new branch "net5" off of my "ilogger" mid-rebase branch, and
> changed me to branch "net5".  I cannot change back to "ilogger" ("error:
> you need to resolve your current index first"), and it appears I will need
> to finish my rebase on "net5".  Even after I do that, I'm not sure what
> state "ilogger" will be in.
> 
> *What's different between what you expected and what actually happened?*
> 
> I think the proper bahavior is for the "git checkout -b" command to fail
> when the current branch is mid-rebase, just like it does when you run `git
> checkout` without the `-b`.
> 

One thing you could try is "git rebase --abort" to see if it can abort
the rebase and undo things. If that resets the index properly, then use
git reflog to make sure the ilogger branch is restored to the pre-rebase
state, or possibly use it on HEAD to find any intermediate commits/edits
you may have made while rebasing.

Re: bug report: I was allowed to "git checkout -b" while mid-rebase

[Grant Birchmeier]

(replying to both Jacob Keller and Phil Hord in here)

Jacob Keller wrote:
> One thing you could try is "git rebase --abort" to see if it can abort
> the rebase and undo things. If that resets the index properly, then use
> git reflog to make sure the ilogger branch is restored to the pre-rebase
> state, or possibly use it on HEAD to find any intermediate commits/edits
> you may have made while rebasing.

Yeah... except I am partway through the rebase.  I was through like 6
of 8 files that needed manual intervention.  Was hoping I wouldn't
lose that.

Though now that I think about it, I suppose I can copy the
already-rebased files into a temp dir, then abort, then copy them
back.  That would be an effective workaround.

Phil Hord wrote:
> You did pick up an extra branch "net5" which will follow your rebase.  But you should find when the rebase completes that both "net5" and "ilogger" point to the tip of your rebased branch.

Oh, really, that's interesting.  I'll see what happens.  (Tomorrow.)

Thank for explaining the technical reason why "git checkout" w/wo "-b"
behaves differently in this regard.  But this can't be an intentional
design choice, or a behavior that even a moderately-experienced user
would expect.

-Grant


-- 
Grant Birchmeier
Director of Engineering, Connamara
gbirchmeier@connamara.com

-- 
This email, along with any attachments, is confidential. If you believe you 
received this message in error, please contact the sender immediately and 
delete all copies of the message. Thank you from Connamara Systems, LLC.

Re bug report: I was allowed to "git checkout -b" while mid-rebase

[K Jayatheerth]

Oh I had a funny story with rebase too...
Now that I think about it, I think rebase should have some confirmation 
like Y/N type.

I had a similar problem although it was just majorly me being clumsy,
I had rebased and forgot to continue, and formatted patch and then
I didn't see the files it created and sent the email
with *.patch pathspec.

And that made me realise just after hitting enter that I sent a patch 
with a previous commit You can find the thread here.[1]

So I believe there must be a confirmation with a warning something like
Y/N so that people are sure that they are doing stuff like creating a new branch within 
rebase or even sending an email or formatting the patch.

1 - https://lore.kernel.org/git/20250524073055.58092-2-jayatheerthkulkarni2005@gmail.com/

Re: bug report: I was allowed to "git checkout -b" while mid-rebase

[Junio C Hamano]

Grant Birchmeier <gbirchmeier@connamara.com> writes:

> *What did you expect to happen? (Expected behavior)*
>
> I would expect an error message and a refusal to execute the `git checkout
> -b` command.

I am not sure if it is such a good idea, though.

I just did a short experiment:

 * randomly work and end up with many commits on 'master'; they are
   about two independent topics A and B, so I want to separate them out.

 * "git rebase -i master" and edit the todo list to group the
   commits into two sets, the commits about the topic A comes first
   and then the commits about the topic B on top.

 * Arrange that before processing the first commit for topic B, the
   control is given back to the end user.  If the last commit of the
   topic A stops due to conflict, that is fine.  Or an explicit
   "break" inserted into the todo list would work well.

 * When topic A's commits are replayed on top of 'master', do "git
   branch A" and then "git checkout -b B master".  The history
   recorded on branch A is now about the development of topic A on
   top of master, without a trace of any topic B.

 * "git rebase --continue" and I ended up on branch B, which
   recorded the development of topic B on top of master, without a
   trace of any topic A.

and it seems to work as expected as a handy way to clean up a mixed
bag into separate topic branches.