Re: aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written

[Eugene Sajine <euguess@gmail.com>]

2010/2/3 SZEDER Gábor <szeder@ira.uka.de>:
> On Wed, Feb 03, 2010 at 10:08:50AM +0100, Johannes Schindelin wrote:
>> Hi,
>>
>> On Wed, 3 Feb 2010, Matthieu Moy wrote:
>>
>> > Strictly speaking, an empty [rebase -i] todolist should mean to drop all
>> > the patches (like a todolist with just one line would mean to drop all
>> > the others). But a user never wants to do that (otherwise, "git reset"
>> > would be the right command), so "git rebase -i" considers it as a
>> > special case.
>>
>> Actually, it is a design bug, but it was the only sane way I could think
>> of aborting the rebase.
>>
>> Note that there _are_ users who want to do that ("let me see what commits
>> I have, ah, oh, okay, I want none of them"). I am one of those.
>
> I regularly mess up the todo file so badly that I don't want to bother
> with undo but rather start over from the beginning.
>
>
> Best,
> Gábor
>
>

I already described the solution which i think should be implemented
in old thread I will just repeat it here for easier tracking:

The solution should be as Avery proposed - to monitor file
modification timestamp as well as the content.
Timestamp should be remembered by git when editor is fired up and then
checked when you're exiting the editor. If it is the same - it means
that user canceled the whole operation by *not* confirming the file
content by save. If the timestamp is bigger than the saved one and the
message is not empty - we can proceed.

I.e. in case of rebase -i you will be able to abort the operation by
simply exiting the editor without save in any state at any moment and
start from the beginning.

Thanks,
Eugene