On 28 December 2013 21:10, Rene Rivera wrote:
I didn't get a chance to try that.. Instead I did a reset (I tried 3 different ways with Egit). It was a hard reset.. Then followed by reverting the commit that was causing me problems.. Unfortunately this removed all the changes in the commit. Instead of the one file I wanted to revert.
That's because a Git commit tracks the state of the entire repository, not of individual files.
I have no idea how to revert *just* *one* *file*.
You can make a single file in your workspace contain the contents of a specific revision with "checkout" git checkout <commit> -- <file> e.g. to change the file 'foobar' to its previously committed state: git checkout HEAD^ -- foobar (HEAD is the current revision, HEAD^ is the previous one). That alters the file in your workspace, it doesn't alter the index or committed tree, so "git status" will show the file as having uncommitted changes.
I then found out when trying to do the merge that git had decided to irreparably delete changes
Git didn't decide to do that - it was probably you by doing a hard reset. That's a sharp tool that should be used carefully.
I had made that somehow my local commit had not saved.
If your commit didn't save it then that's because you didn't commit the changes.
I only saved myself as I had older copies of the deleted files.
Anything which has been committed at some point can be retrieved (at least until it gets garbage collected a few weeks later). "git reflog" will allow you to find the commit IDs of "lost" commits, and generally show you what you've done recently to alter the state of your repo. But changes that were never committed can be easily lost, via careless use of "reset" or other commands that explicitly throw away uncommitted changes. For good reason Git is called a "dumb content tracker", it doesn't try to do clever things or decide what's best for you, it just does what you tell it. (Unfortunately learning how to say what you want can be conceptually difficult and has a steep learning curve).