Armin Ronacher venit, vidit, dixit 16.02.2015 14:29: > 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 > Are you concerned about the index only, not unstaged worktree changes? In this case, keeping a reflog for the index may help, and it would somehow fit into the overall concept. Otherwise, we would basically need a full stash before a hard reset. That's not the first time where we could need a distinction between "command run by user" and "command run by script". For the former, we could allow overriding default options, re-aliasing internal commands, adding expensive safety hooks. For the latter we can't. It's just that we don't have such a concept yet (other than checking tty). Michael -- 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