Re: [BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote:
> I do not think --abort was designed to abort an uncontrolled stop
> like ^C in the first place.

Why not? All it requires is a reset --hard to
.git/rebase-apply/head-name, as usual, no?

> To allow that kind of "recovery", you
> need to teach "rebase" to first record the state you would want to
> go back to before doing anything, but then what happens if the ^C
> comes when you are still in the middle of doing so?

I'm a bit puzzled: doesn't rebase write_basic_state() as soon as it
starts? It's true that we can't recover from a ^C before that, but I
would expect to be able to recover after a ^C somewhere in the middle.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Junio C Hamano
Ramkumar Ramachandra  writes:

> Hi,
>
> On the latest git, I noticed that a rebase --onto doesn't abort
> properly. Steps to reproduce:
>
>   # on some topic branch
>   $ git rebase --onto master @~10
>   ^C # quickly!
>   $ git rebase --abort
>   # HEAD is still detached

I do not think --abort was designed to abort an uncontrolled stop
like ^C in the first place.  To allow that kind of "recovery", you
need to teach "rebase" to first record the state you would want to
go back to before doing anything, but then what happens if the ^C
comes when you are still in the middle of doing so?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html