Re: [RFC PATCH] revert: Implement --abort processing

Ramkumar Ramachandra <artagnon@gmail.com> writes:

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.