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

[ message continues ]

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

[ message continues ]

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



--

[ message continues ]

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

--

[ message continues ]

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

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

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

[ message continues ]

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

--

[ message continues ]