Re: Experience with Recovering From User Error (And suggestions for improvements)
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
Experience with Recovering From User Error (And suggestions for improvements)
Hi, Long story short: I failed big time yesterday with accidentally executing git reset hard in the wrong terminal window but managed to recover my changes from the staging area by manually examining blobs touched recently. After that however I figured I might want to add a precaution for myself that would have helped there. git fsck is quite nice, but unfortunately it does not help if you do not have a commit. So I figured it might be nice to create a dangling backup commit before a reset which would have helped me. Unfortunately there is currently no good way to hook into git reset. Things I noticed in the process: * for recovering blobs, going through the objects itself was more useful because they were all recent changes and as such I could order by timestamp. git fsck will not provide any timestamps (which generally makes sense, but made it quite useless for me) * Recovering from blobs is painful, it would be nice if git reset --hard made a dangling dummy commit before :) * There is no pre-commit hook which could be used to implement the previous suggestion. Would it make sense to introduce a `pre-commit` hook for this sort of thing or even create a dummy commit by default? I did a quick googling around and it looks like I was not the first person who made this mistake. Github's windows client even creates dangling backup commits in what appears to be fixed time intervals. I understand that ultimately this was a user error on my part, but it seems like a small change that could save a lot of frustration. 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
git clone on out-of-space device causes incorrect errors
Hi, When cloning onto a device that is out of space to fulfill the whole clone operation, git will report that the remove repository does not exist: $ git clone https://github.com/mozilla/flask Cloning into 'flask'... remote: Repository not found. fatal: repository 'https://github.com/mozilla/flask/' not found This error is misleading. As an example here is what hg does for the same situation: $ hg clone https://bitbucket.org/dholth/wheel destination directory: wheel requesting all changes adding changesets adding manifests adding file changes transaction abort! failed to truncate 00changelog.i rollback failed - please run hg recover abort: No space left on device: /Volumes/Disk Image/wheel/.hg/store/.fncache-bt6dzr 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
