Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html