8 ms·
> Git will let you blow away a month's work if you mistype a command. It's sad to hear someone say that, presumably you've been bitten by it. What you describ
by jlebar 7y ago
> Git will let you blow away a month's work if you mistype a command.
It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
- KaoruAoiShiho 7y ago> While it's easy to blow away work you haven't committed This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.
- jlebar 7y agoI don't believe hg is any better in this respect.
- yjftsjthsd-h 7y agoI can tell you that it is in at least one use case that I've hit. If you have local uncommitted changes to a file, and then run `hg revert file` to undo your changes, it creates (by default) a ".orig" backup. The equivalent git command (`git checkout --hard` or something?) will just throw out local changes with no takebacks.
- philpem 7y agoI would absolutely love it if Git had this feature. Having it on Hg has saved me so many times.
- philpem 7y agoI've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit. Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try. Management asked "what if you do that with Mercurial?" Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can. TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.
- dajohnson89 7y agoYou know that you can revert a revert, right?
- phaemon 7y ago> Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try. Was "asking someone who knows how git works" on your list of things to try? What about "learning how git works"? Was that on your list? Frankly, you don't seem to have been trying very hard to get this work back.
- nerdponx 7y agoThat's not the point, the point is that Git is a really bad interface to a really powerful system.
- ozim 7y agoHave you tried to operate an excavator? That thing is complicated compared to a car... But you know what? That is specialist tool. If you cannot operate with specialist tools you should not get a job of a specialist. I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76 https://wordpress.com/post/squarebits.wordpress.com/76
- dreamcompiler 7y ago> every commit you've made in the past month is saved in the reflog I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."
- bschwindHN 7y agoJust in the case you didn't know, you can view the reflog with `git reflog` From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.