{"thread":{"id":"63670","subject":"bug report: I was allowed to \"git checkout -b\" while mid-rebase","startedAt":"2025-06-19T00:12:14Z","lastAt":"2025-06-19T17:32:01Z","messageCount":5,"participants":["Grant Birchmeier","Jacob Keller","K Jayatheerth","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"520390","messageId":"CAMq4opPBGT0Rv25DnEMHPjA=W_Ut2BDsN0KmxD2_xGTJa9erJQ@mail.gmail.com","threadId":"63670","inReplyTo":null,"subject":"bug report: I was allowed to \"git checkout -b\" while mid-rebase","fromName":"Grant Birchmeier","fromEmail":"gbirchmeier@connamara.com","sentAt":"2025-06-19T00:12:01Z","receivedAt":"2025-06-19T00:12:14Z","isPatch":false,"sender":{"key":"gbirchmeier@connamara.com","avatar":null},"body":"Hello. I've attached my git-bugreport, but I'll copy/paste the salient\nparts here. Thanks. Let me know if I can provide anything else.\n\n*What did you do before the bug happened? (Steps to reproduce your issue)*\n\nI was rebasing a branch \"ilogger\" on my master branch. While this rebase\nwas still open, I accidentally ran `git checkout -b net5` (I meant to run\nit in a different console)... and it proceeded to switch me to the new\nbranch even though the the rebase was still in progress.\n\n*What did you expect to happen? (Expected behavior)*\n\nI would expect an error message and a refusal to execute the `git checkout\n-b` command.\n\n*What happened instead? (Actual behavior)*\n\nIt created a new branch \"net5\" off of my \"ilogger\" mid-rebase branch, and\nchanged me to branch \"net5\". I cannot change back to \"ilogger\" (\"error:\nyou need to resolve your current index first\"), and it appears I will need\nto finish my rebase on \"net5\". Even after I do that, I'm not sure what\nstate \"ilogger\" will be in.\n\n*What's different between what you expected and what actually happened?*\n\nI think the proper bahavior is for the \"git checkout -b\" command to fail\nwhen the current branch is mid-rebase, just like it does when you run `git\ncheckout` without the `-b`.\n\n\n-- \n\n\nGrant Birchmeier\n\nDirector of Engineering, Connamara\n\ngbirchmeier@connamara.com\n\n-- \nThis email, along with any attachments, is confidential. If you believe you \nreceived this message in error, please contact the sender immediately and \ndelete all copies of the message. Thank you from Connamara Systems, LLC.\n\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nI 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.\n\nWhat did you expect to happen? (Expected behavior)\n\nI would expect an error message and a refusal to execute the `git checkout -b` command.\n\nWhat happened instead? (Actual behavior)\n\nIt 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.\n\nWhat's different between what you expected and what actually happened?\n\nI 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`.\n\nAnything else you want to add:\n\n(nothing)\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.45.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: 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\ncompiler info: clang: 15.0.0 (clang-1500.3.9.4)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\n"},{"id":"520391","messageId":"30cf835f-925c-4d33-a353-ee42e712fed7@intel.com","threadId":"63670","inReplyTo":"CAMq4opPBGT0Rv25DnEMHPjA=W_Ut2BDsN0KmxD2_xGTJa9erJQ@mail.gmail.com","subject":"Re: bug report: I was allowed to \"git checkout -b\" while mid-rebase","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2025-06-19T00:19:30Z","receivedAt":"2025-06-19T00:19:49Z","isPatch":false,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"\n\nOn 6/18/2025 5:12 PM, Grant Birchmeier wrote:\n> Hello. I've attached my git-bugreport, but I'll copy/paste the salient\n> parts here. Thanks. Let me know if I can provide anything else.\n> \n> *What did you do before the bug happened? (Steps to reproduce your issue)*\n> \n> I was rebasing a branch \"ilogger\" on my master branch. While this rebase\n> was still open, I accidentally ran `git checkout -b net5` (I meant to run\n> it in a different console)... and it proceeded to switch me to the new\n> branch even though the the rebase was still in progress.\n> \n> *What did you expect to happen? (Expected behavior)*\n> \n> I would expect an error message and a refusal to execute the `git checkout\n> -b` command.\n> \n> *What happened instead? (Actual behavior)*\n> \n> It created a new branch \"net5\" off of my \"ilogger\" mid-rebase branch, and\n> changed me to branch \"net5\". I cannot change back to \"ilogger\" (\"error:\n> you need to resolve your current index first\"), and it appears I will need\n> to finish my rebase on \"net5\". Even after I do that, I'm not sure what\n> state \"ilogger\" will be in.\n> \n> *What's different between what you expected and what actually happened?*\n> \n> I think the proper bahavior is for the \"git checkout -b\" command to fail\n> when the current branch is mid-rebase, just like it does when you run `git\n> checkout` without the `-b`.\n> \n\nOne thing you could try is \"git rebase --abort\" to see if it can abort\nthe rebase and undo things. If that resets the index properly, then use\ngit reflog to make sure the ilogger branch is restored to the pre-rebase\nstate, or possibly use it on HEAD to find any intermediate commits/edits\nyou may have made while rebasing.\n\n"},{"id":"520394","messageId":"CAMq4opMBpg4315Q8awm5SQAQa1vms=3KB+SiQkGtCF7thBPjHw@mail.gmail.com","threadId":"63670","inReplyTo":"CABURp0orQ-UCzDgJc=STPQZaaEEGwR0GM-GZq_Ty3BXBKYS2iQ@mail.gmail.com","subject":"Re: bug report: I was allowed to \"git checkout -b\" while mid-rebase","fromName":"Grant Birchmeier","fromEmail":"gbirchmeier@connamara.com","sentAt":"2025-06-19T02:30:04Z","receivedAt":"2025-06-19T02:30:17Z","isPatch":false,"sender":{"key":"gbirchmeier@connamara.com","avatar":null},"body":"(replying to both Jacob Keller and Phil Hord in here)\n\nJacob Keller wrote:\n> One thing you could try is \"git rebase --abort\" to see if it can abort\n> the rebase and undo things. If that resets the index properly, then use\n> git reflog to make sure the ilogger branch is restored to the pre-rebase\n> state, or possibly use it on HEAD to find any intermediate commits/edits\n> you may have made while rebasing.\n\nYeah... except I am partway through the rebase. I was through like 6\nof 8 files that needed manual intervention. Was hoping I wouldn't\nlose that.\n\nThough now that I think about it, I suppose I can copy the\nalready-rebased files into a temp dir, then abort, then copy them\nback. That would be an effective workaround.\n\nPhil Hord wrote:\n> 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.\n\nOh, really, that's interesting. I'll see what happens. (Tomorrow.)\n\nThank for explaining the technical reason why \"git checkout\" w/wo \"-b\"\nbehaves differently in this regard. But this can't be an intentional\ndesign choice, or a behavior that even a moderately-experienced user\nwould expect.\n\n-Grant\n\n\n-- \nGrant Birchmeier\nDirector of Engineering, Connamara\ngbirchmeier@connamara.com\n\n-- \nThis email, along with any attachments, is confidential. If you believe you \nreceived this message in error, please contact the sender immediately and \ndelete all copies of the message. Thank you from Connamara Systems, LLC.\n"},{"id":"520397","messageId":"20250619083556.10619-1-jayatheerthkulkarni2005@gmail.com","threadId":"63670","inReplyTo":"CAMq4opMBpg4315Q8awm5SQAQa1vms=3KB+SiQkGtCF7thBPjHw@mail.gmail.com","subject":"Re bug report: I was allowed to \"git checkout -b\" while mid-rebase","fromName":"K Jayatheerth","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2025-06-19T08:35:56Z","receivedAt":"2025-06-19T08:36:07Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Oh I had a funny story with rebase too...\nNow that I think about it, I think rebase should have some confirmation \nlike Y/N type.\n\nI had a similar problem although it was just majorly me being clumsy,\nI had rebased and forgot to continue, and formatted patch and then\nI didn't see the files it created and sent the email\nwith *.patch pathspec.\n\nAnd that made me realise just after hitting enter that I sent a patch \nwith a previous commit You can find the thread here.[1]\n\nSo I believe there must be a confirmation with a warning something like\nY/N so that people are sure that they are doing stuff like creating a new branch within \nrebase or even sending an email or formatting the patch.\n\n1 - https://lore.kernel.org/git/20250524073055.58092-2-jayatheerthkulkarni2005@gmail.com/\n"},{"id":"520416","messageId":"xmqq34bvab8x.fsf@gitster.g","threadId":"63670","inReplyTo":"CAMq4opPBGT0Rv25DnEMHPjA=W_Ut2BDsN0KmxD2_xGTJa9erJQ@mail.gmail.com","subject":"Re: bug report: I was allowed to \"git checkout -b\" while mid-rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-06-19T17:31:58Z","receivedAt":"2025-06-19T17:32:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Grant Birchmeier writes:\n\n> *What did you expect to happen? (Expected behavior)*\n>\n> I would expect an error message and a refusal to execute the `git checkout\n> -b` command.\n\nI am not sure if it is such a good idea, though.\n\nI just did a short experiment:\n\n * randomly work and end up with many commits on 'master'; they are\n about two independent topics A and B, so I want to separate them out.\n\n * \"git rebase -i master\" and edit the todo list to group the\n commits into two sets, the commits about the topic A comes first\n and then the commits about the topic B on top.\n\n * Arrange that before processing the first commit for topic B, the\n control is given back to the end user. If the last commit of the\n topic A stops due to conflict, that is fine. Or an explicit\n \"break\" inserted into the todo list would work well.\n\n * When topic A's commits are replayed on top of 'master', do \"git\n branch A\" and then \"git checkout -b B master\". The history\n recorded on branch A is now about the development of topic A on\n top of master, without a trace of any topic B.\n\n * \"git rebase --continue\" and I ended up on branch B, which\n recorded the development of topic B on top of master, without a\n trace of any topic A.\n\nand it seems to work as expected as a handy way to clean up a mixed\nbag into separate topic branches.\n"}]}