Hi,
On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:
We should definitely make recovery like this harder, but is there a
reason for why you don't use "git reset --keep" instead of --hard?
This was only the second time in years of git usage that the reset was
incorrectly done. I suppose at this point I might try to retrain my
muscle memory to type something else :)
If we created such hooks for "git reset --hard" we'd just need to
expose some other thing as that low-level operation (and break scripts
that already rely on it doing the minimal "yes I want to change the
tree no matter what" thing), and then we'd just be back to square one
in a few years when users started using "git reset --really-hard" (or
whatever the flag would be).
I don't think that's necessary, I don't think it would make the
operation much slower to just make a dangling commit and write out a few
blobs. The garbage collect will soon enough take care of that data
anyways. But I guess that would need testing on large trees to see how
bad that goes.
I might look into the git undo thing that was mentioned.
Regards,
Armin
--
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
