Show 22 quoted lines
>>> 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.