On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener
On 12/28/2013 06:21 PM, Jonathan Wakely wrote:
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.
I am interested in this. Other than the hard reset, which tells git to overwrite the working directory and index, I did not think that git would ever throw away uncomitted changes, whether they are in the working directory or the index. Would you please be specific about any situations where git will overwrite the working directory/index without the user being aware ?
Just about any git command with a (-f | --force) option, e.g. git checkout -f HEAD git submodule update -f etc. Anytime you use a -f option you're telling git, "I know what I'm doing", whether that's true or not. Michael
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost