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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 19, 2025, 17:31 UTC
Message-ID: <xmqq34bvab8x.fsf@gitster.g>
In-Reply-To: <CAMq4opPBGT0Rv25DnEMHPjA=W_Ut2BDsN0KmxD2_xGTJa9erJQ@mail.gmail.com>

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.