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: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-29 03:16:08

On Sat, Dec 28, 2013 at 11:39 PM, Edward Diener <eldiener_at_[hidden]>wrote:

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