>>> In most cases, this is just a small annoyance, since it's usually >>> quick and easy to manually switch back to the original >>> branch. However, I have run into at least two cases where it has been >>> a bit more annoying: >>> >>> 1. When on a detached HEAD and running "git rebase HEAD topic", if >>> you abort the rebase, you will have to look up the old commit in >>> the reflog. >> >> Doesn't this merely show a bad discipline? What were you envisioning to >> do to your detached HEAD state if the rebase were to succeed? IOW, if the >> state was so precious, why did you decide to switch to topic and rebase it >> onto that state, without marking? > > This usually happens when I see something that looks a bit suspicious > in one of my own commits on my topic branch. I then check out that > commit to have a look and perhaps run some test. If I find something > broken, I would fix it and either amend the commit or create a new > commit on top. I would then run "git rebase --onto HEAD HEAD~1 topic" > or "git rebase HEAD topic", respectively. If the merge conflicts turn > out to be bigger than I expected, I may decide to abort and to instead > create a new branch for the commit(s) until I find time/energy. This can be easily fixed for your own repository by installing a pre-rebase hook that force-sets a temporary branch (named e.g. "pre-rebase") to the current commit before starting the rebase. I can highly recommend having such a hook, it's damn useful. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html