Grant Birchmeier <gbirchmeier@xxxxxxxxxxxxx> 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.
