Re: [boost] [git-help][urgent] How do I ignore an upstream change to one file?

Subject: Re: [boost] [git-help][urgent] How do I ignore an upstream change to one file?
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-29 01:39:24

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 ?