Kyle J. McKay venit, vidit, dixit 19.02.2015 02:17: > On Feb 18, 2015, at 01:46, Michael J Gruber wrote: >> 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. > > There was this concept of a git stash checkpoint to save work in > progress without creating a normal commit that I read about some time > ago (blog? Git book? -- don't recall) that was basically just this: > > git stash save > git stash apply > > The problem with that is that it touches the working tree and can > trigger rebuilds etc. However, when I ran across the undocumented > "git stash create" command I was able to write a simple git-checkpoint > script [1] that creates a new stash entry without touching the index > or working tree which I find quite handy from time to time.
I think that would make for a nice additional command/mode that we could support for git-stash.sh. Alle the pieces are there. > So I think that what Armin originally asked for (create a dangling > commit of changes before reset --hard) could be accomplished simply by > running: > > git checkpoint && git stash drop > >> 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). > > But of course plugging that into git reset somehow is indeed the > problem since you cannot alias/redefine git commands. > > -Kyle > > [1] https://gist.github.com/mackyle/83b1ba13e263356bdab0 Also, "git stash create" does the tree creation and object creation that we wanted to avoid at least for scripts. And "git reset --hard-but-safe" suffers from the user education problems that have been mentioned already. Michael -- 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
