From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 01 Jun 2011 17:38:10 GMT
Subject: Re: [RFC PATCH] revert: Implement --abort processing
Message-ID: <7vfwnth2pp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1306944446-11031-1-git-send-email-artagnon@gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> To abort, perform a "rerere clear" and "reset --hard" to the ref
> specified by the HEAD file introduced earlier in the series.

What is the scenario this new feature targets? Is it to recover from this?

    % git revert $that_single_faulty_commit
    ... oops conflicted, let's try if I can resolve ...
    % edit $conflicted_files
    ... yuck, I managed to resolve two paths but not other three ...
    ... let's give up for now ...

In that scenario, a recovery may involve "git reset --hard", but clearing
the rerere record for what you have already resolved may or may not be.  I
would imagine that the above "give up _for now_" would be concluded with:

    % git add $files_i_managed_to_resolve_this_round
    % git rerere
    $ git reset --hard

Even if you dropped the unconditional "rerere clear" from the patch, I am
not sure what this new feature buys us. Some people would want the rerere
cache cleared, some others don't. "revert --abort" will forever be to
aborting revert and restoring some but not all the parts of the operation
the user wants to be undone, as you cannot satisfy everybody.  So I am a
bit puzzled why you thought this was even a good idea to begin with.

"reset --hard" has established semantics people already understand what it
does. I would rather see us let them use that, without confusing them with
"what are the differences between the two?" unnecessarily.