A few days ago I ran into the old shooting yourself in the foot with a programming language jokes. And then again a day later, it appeared in #vala. At some point today or yesterday I had a mishap with git history editing and have, umm, shot myself in the foot.
In your hands you hold a powerful sniper rifle. Those familiar with it consider it the most impressive and technologically advanced sniper rifle in the world. It is the quickest way to shoot, with bullets travelling at up to Mach 3. Multiple enemies are dead before a single shot is heard.
Impressed at your choice of sniper rifle, you reach to turn off the safety and realise that it doesn’t have one. You reach for the trigger, only to find it is not where you normally expect to find a trigger.
After seeking advice, you are advised to read about the internals of the sniper rifle (its manufacturers say that understanding how the sniper rifle is built is the only way to get the most out of a sniper rifle) you are ready. You start to shoot enemies and find yourself somewhat joyful at the amount of power you are wielding. You feel in control. You feel liberated. Pow pow pow. How did I get anything done before I had this beast?
All your friends, feeling left behind, get one too.
At some point you look down and you realise you shot your foot, a large chunk of it is now missing. Oh well, the pieces are still around if you look hard enough. Here’s a sewing kit.
Luckily I only lost 2 files, which were pretty much unchanged from master. The rest I think I can still get to just by splitting surviving commits. And just when I thought I was about to level up my git abilities too.
(Disclaimer: This is not a cry for help, nor is it a call for flaming, just an unfunny “OMG I SHOT MYSELF IN THE FOOT”).
Tags: Git
Ah, you can’t leave us hanging like that. We want to know what mistake you made.
I’m pretty curious because I find it incredibly difficult in git to lose any recorded history at all. Even when editing history in git, the original version is still around and available via the reflog for a very long time (granted, not everyone knows about the reflog). It is easy to lose data in the working copy that hasn’t been committed yet (git reset –hard, git stash && git stash clear, probably others…), but you said it had to do with history editing.
Fun post, though.
Ah, technically I didn’t lose history (I tried not to say that I had..). I still consider this a shot myself in the foot though.
Essentially i was reviewing the same set of 12 commits over and over again. At some point i did git reset HEAD, made some changes and produced 2 commits from one, but failed to git add some files. I edited the series some more and at some point had to remove some stray header files that were interfering with gtk-doc. Little did I realise that these were the freshly unversioned history. Then i edited some more. All of a sudden, make distcheck on HEAD was failing. I realise my mistake, the headers i just deleted were from a commit i cocked up. ARRRGH.
(There was a secondary cockup that I can’t even explain what happened).
At this point, my tree is small enough and my hacking recent enough that I can reconstruct everything easily, but otherwise its a case of looking through the reflog. It all looks a bit.. “You will be punished for being a noob”.
But I mean, if I’d git gc’d the history would be gone, right? Or if I’d gone over 50 commits I’d have triggered an auto gc and this would be gone. It kind of feels like I’m sifting through the debris that is only still around as a by-product of the original design rather than some desire for you not to loose history….
@John: No, git gc would not remove the history because the reflog still has a reference to it. Only once it expired from the reflog would git gc remove it.
@Anonymous Coward: Cool, thats not so bad then. Reading the man pages this has not always been the case (there is a command to fix stale refs, and it mentions pruning is now reflog aware) – any idea when they fixed it?
Also, do you have any ninja jitsu for sifting through the reflog for my missing chunks? (For future reference). I guess git reflog –stat would be a start.. So I could see which entries are related to the files I screwed up.