Daniel, at work, ran into a problem of accidentally removing a branch he had just created and made a commit to, thus loosing the days work. This was actually the fault of our internal scripts to manage the branching and merging policy we've set up. By "internal" I mean that I wrote them and it was my fault his whole day of work was gone, so that left it up to me to figure out how to repair the situation and salvage the current commit back from the ether. I thought it might be good to document, in the case that anyone else needs to do this.
This works in the case of branch A existing and branch B being removed after a single commit on it and branch B being from A. This means we know commit A and we need to find an unnamed commit, what was B, to recover it.
I can demonstrate the recovery process with a simple transcript.
The red line is the dangerous move that lost your commit. Now, nothing is actually removed from the repository, except for when you perform a garbage collection, so I knew we could recover this somehow. After a short time looking through the docs and asking a question or two on IRC, I arrived at the solution. There are logs kept on the changes that happen to refs (or branches), so I could use that to see the log of when that commit happened. You can see that and the commit the follows when the reset occurs and undoes our commit. The commit id is in the short version, but if we look at the log of that commit, we get the full ID and can simply merge it back into our branch. A very clean solution, indeed.
For Daniel This Means...
He didn't loose his whole days work, but he should be doing local commits more often so that any problems with our scripts can't show up in the first place. At least the work was recovered, and in short time. He is saved, for one more day at least, from being a disgruntled co-worker.
For Git This Means...
I'd love to contribute, so I'm thinking the git-fsck command needs something that can do this for you. Some operation to locate child commits would be really useful in these situations. Once again, I'm very happy with the move to Git.
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.
- ► 2014 (51)
- ► 2012 (19)
- ► 2011 (19)
- ► 2010 (32)
- ► 2008 (28)
- ▼ December (6)