git pull (Your local changes to ... would be overwritten by merge)

git pull (Your local changes to ... would be overwritten by merge)

[Daniel Blendea]

Hello,

A while ago I have cloned on my computer a git repo.
Since then, the developers have modified several files in the repo.
Now I want to update my copy with the latest changes.

I do 'git pull' but I get 'Your local changes to .... would be
overwritten by merge.  Aborting.'
I didn't modified any local file. I tried using 'git stash save' but no luck.

How can I make git update and override my local copy?
With all the fuss about it, I thought I will handle this operation
pretty easily.

Thank you,
Daniel

Re: git pull (Your local changes to ... would be overwritten by merge)

[Santi Béjar]

On Thu, Jun 17, 2010 at 11:35 AM, Daniel Blendea <bdaniel7@gmail.com> wrote:
> Hello,
>
> A while ago I have cloned on my computer a git repo.
> Since then, the developers have modified several files in the repo.
> Now I want to update my copy with the latest changes.
>
> I do 'git pull' but I get 'Your local changes to .... would be
> overwritten by merge.  Aborting.'
> I didn't modified any local file. I tried using 'git stash save' but no luck.

Are they known to git? What is their status (git status)?

If they are not known to git, it seams that there are *new* files both
in the remote branch and the working copy (new files in the working
copy are not saved with 'git stash save').

I would rename/mv the conflicting new files in the working copy,
perform the pull and maybe compare the new files from the branch with
the ones from the working copy.

HTH,
Santi

Re: git pull (Your local changes to ... would be overwritten by merge)

[Daniel Blendea]

I have no idea, I know git just barely to be able to update my copy
once in a while, then build it to get the binaries.
I didn't modified anything and the build script builds the binaries in
a different location.

The file which threw the first error was already in my copy and it was
modified in the remote branch.
---
Daniel



On Thu, Jun 17, 2010 at 12:46, Santi Béjar <santi@agolina.net> wrote:
> On Thu, Jun 17, 2010 at 11:35 AM, Daniel Blendea <bdaniel7@gmail.com> wrote:
>> Hello,
>>
>> A while ago I have cloned on my computer a git repo.
>> Since then, the developers have modified several files in the repo.
>> Now I want to update my copy with the latest changes.
>>
>> I do 'git pull' but I get 'Your local changes to .... would be
>> overwritten by merge.  Aborting.'
>> I didn't modified any local file. I tried using 'git stash save' but no luck.
>
> Are they known to git? What is their status (git status)?
>
> If they are not known to git, it seams that there are *new* files both
> in the remote branch and the working copy (new files in the working
> copy are not saved with 'git stash save').
>
> I would rename/mv the conflicting new files in the working copy,
> perform the pull and maybe compare the new files from the branch with
> the ones from the working copy.
>
> HTH,
> Santi
>

Re: git pull (Your local changes to ... would be overwritten by merge)

[Michael J Gruber]

Daniel Blendea venit, vidit, dixit 17.06.2010 11:35:
> Hello,
> 
> A while ago I have cloned on my computer a git repo.
> Since then, the developers have modified several files in the repo.
> Now I want to update my copy with the latest changes.
> 
> I do 'git pull' but I get 'Your local changes to .... would be
> overwritten by merge.  Aborting.'
> I didn't modified any local file. I tried using 'git stash save' but no luck.
> 
> How can I make git update and override my local copy?
> With all the fuss about it, I thought I will handle this operation
> pretty easily.

If you are sure you have no own modifications which you would miss:

git fetch --all
git reset --hard origin/master

Fetch is pull without trying to merge or rebase anything.
the send line resets your master branch to what you just fetched.

Most likely the remote side did a non-forward push and brought you in
that situation.

[Which, on a side note, is one reason why I still believe that git
should not create any local branch for a clone. git fetch && git
checkout origin/master does not suffer from this issue.]

Michael

Re: git pull (Your local changes to ... would be overwritten by merge)

[Matthieu Moy]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Daniel Blendea venit, vidit, dixit 17.06.2010 11:35:
>> Hello,
>> 
>> A while ago I have cloned on my computer a git repo.
>> Since then, the developers have modified several files in the repo.
>> Now I want to update my copy with the latest changes.
>> 
>> I do 'git pull' but I get 'Your local changes to .... would be
>> overwritten by merge.  Aborting.'
>> I didn't modified any local file. I tried using 'git stash save' but no luck.

Which OS? Do you have any crlf conversion enabled? Any filter set in
.gitattributes?

> Most likely the remote side did a non-forward push and brought you in
> that situation.

A non-fast forward push would force a non-fast forward pull,
possibly/probably with conflicts, but wouldn't trigger this message,
which is generated before the merge is actually started.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git pull (Your local changes to ... would be overwritten by merge)

[Daniel Blendea]

Windows 7, did not change anything related to crlf.

I solved the problem with

git fetch --all
git reset --hard origin/master

---
Daniel



On Thu, Jun 17, 2010 at 14:11, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Daniel Blendea venit, vidit, dixit 17.06.2010 11:35:
>>> Hello,
>>>
>>> A while ago I have cloned on my computer a git repo.
>>> Since then, the developers have modified several files in the repo.
>>> Now I want to update my copy with the latest changes.
>>>
>>> I do 'git pull' but I get 'Your local changes to .... would be
>>> overwritten by merge.  Aborting.'
>>> I didn't modified any local file. I tried using 'git stash save' but no luck.
>
> Which OS? Do you have any crlf conversion enabled? Any filter set in
> .gitattributes?
>
>> Most likely the remote side did a non-forward push and brought you in
>> that situation.
>
> A non-fast forward push would force a non-fast forward pull,
> possibly/probably with conflicts, but wouldn't trigger this message,
> which is generated before the merge is actually started.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>

Re: git pull (Your local changes to ... would be overwritten by merge)

[Michael J Gruber]

Daniel Blendea venit, vidit, dixit 17.06.2010 13:18:
> Windows 7, did not change anything related to crlf.
> 
> I solved the problem with
> 
> git fetch --all
> git reset --hard origin/master

I guess this shows that correct diagnostics is not a prerequisite for a
successful therapy ;)

(The diagnostics really indicate a work tree with local uncommitted
modifications.)

Michael

Re: git pull (Your local changes to ... would be overwritten by merge)

[Matthieu Moy]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Daniel Blendea venit, vidit, dixit 17.06.2010 13:18:
>> Windows 7, did not change anything related to crlf.

I never used Git on Windows, but I think Git sets autocrlf to true by
default on Windows.

> I guess this shows that correct diagnostics is not a prerequisite for a
> successful therapy ;)
>
> (The diagnostics really indicate a work tree with local uncommitted
> modifications.)

I'd bet for this kind of issue:

http://kerneltrap.org/mailarchive/git/2010/3/9/25215/thread
From: Johannes Schindelin
Subject: core.autocrlf considered half-assed

Didn't follow the outcome in details, but some patches were proposed
to improve the situation.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git pull (Your local changes to ... would be overwritten by merge)

[Eyvind Bernhardsen]

On 17. juni 2010, at 17.21, Matthieu Moy wrote:

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> I guess this shows that correct diagnostics is not a prerequisite for a
>> successful therapy ;)
>> 
>> (The diagnostics really indicate a work tree with local uncommitted
>> modifications.)
> 
> I'd bet for this kind of issue:
> 
> http://kerneltrap.org/mailarchive/git/2010/3/9/25215/thread
> From: Johannes Schindelin
> Subject: core.autocrlf considered half-assed
> 
> Didn't follow the outcome in details, but some patches were proposed
> to improve the situation.

Finn Arne Gangstad's "safe autocrlf" patch (c480539, currently in next) solves the problem by disabling conversion for files that contain CRs in the repository.
-- 
Eyvind Bernhardsen