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: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2013-12-28 18:21:14

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).