(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@xxxxxxxxxxxxx -- 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.
