threads / discuss / 20811

Problems with GIT under Windows - "not uptodate"

Subject: Problems with GIT under Windows - "not uptodate"

## tl;dr

7 messages between Sep 1, 2009 and Sep 1, 2009.

replies: 6people: 4as markdown or json

david.hagood@gmail.com· Sep 1, 2009, 15:46 UTC · lore

I am having a problem trying to support my poor, deluded cow-orkers who use Windows and need to use GIT.

The scenario goes something like this:

They have a local repo, they have changes on their branch, they are staging a commit to the master branch on their local.

They do a "git merge" and the merge has conflicts. They need to undo the merge, so they do a "git reset --hard".

>From that point onward, if they try to access the origin repository (e.g.

"git pull") they get the error message

Error: Entry "Some file name" not uptodate: cannot merge.

We've tried "git reset --hard; git pull ." We've tried "git reset --hard; git checkout -f master". Neither seems to fix this.

We Linux users don't see this.

I conjecture it is something to do with DOS's CR/LF line endings (the files in question are a type of XML file which ALWAYS have CR/LF endings, even under Linux) - perhaps *something* in the GIT processing chain is trying to do a CR/LF -> LF conversion, and screwing things up.

Does anybody have any suggestions on what I am doing wrong (Please, not "you are using Windows")?

Eric Raible· Sep 1, 2009, 16:52 UTC · re: david.hagood@gmail.com · lore

Re: Problems with GIT under Windows - "not uptodate"

 <david.hagood <at> gmail.com> writes:

> Error: Entry "Some file name" not uptodate: cannot merge.
> 
> We've tried "git reset --hard; git pull ." We've tried "git reset --hard;
> git checkout -f master". Neither seems to fix this.

http://article.gmane.org/gmane.comp.version-control.git/122862

Johannes Schindelin· Sep 1, 2009, 22:56 UTC · re: Eric Raible · lore

Re: Problems with GIT under Windows - "not uptodate"

Hi,

Eric, is there any good reason you neglect netiquette? I re-added David to the Cc: list.

On Tue, 1 Sep 2009, Eric Raible wrote:

Show 8 quoted lines

>  <david.hagood <at> gmail.com> writes:
> 
> > Error: Entry "Some file name" not uptodate: cannot merge.
> > 
> > We've tried "git reset --hard; git pull ." We've tried "git reset --hard;
> > git checkout -f master". Neither seems to fix this.
> 
> http://article.gmane.org/gmane.comp.version-control.git/122862

To summarize: the suggestion is "rm .git/index && git reset --hard".

I have to stress the same point as in "reset --hard considered harmful" a while back, though.

Actually, I started writing a patch to provide "git checkout --fix-crlf" some weeks ago, but I constantly run out of time to finish it.

Ciao, Dscho

Eric Raible· Sep 1, 2009, 23:16 UTC · re: Johannes Schindelin · lore

Re: Problems with GIT under Windows - "not uptodate"

On Tue, Sep 1, 2009 at 3:56 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:

> Hi,
>
> Eric, is there any good reason you neglect netiquette?  I re-added David
> to the Cc: list.

Thanks. Frankly I (stupidly) assumed that gmane.org would handle it. Educate me (if you would): if I read the git list via gmane, what's the best way to follow up?

Johannes Schindelin· Sep 1, 2009, 23:19 UTC · re: Eric Raible · lore

Re: Problems with GIT under Windows - "not uptodate"

Hi,

On Tue, 1 Sep 2009, Eric Raible wrote:

Show 9 quoted lines

> On Tue, Sep 1, 2009 at 3:56 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > Eric, is there any good reason you neglect netiquette?  I re-added 
> > David to the Cc: list.
> 
> Thanks.  Frankly I (stupidly) assumed that gmane.org would handle it. 
> Educate me (if you would): if I read the git list via gmane, what's the 
> best way to follow up?

No idea. I read the mails in a normal mail program. You'll have to find out yourself how to behave nicely with GMane's interface.

Ciao, Dscho

skillzero@gmail.com· Sep 1, 2009, 18:19 UTC · re: david.hagood@gmail.com · lore

Re: Problems with GIT under Windows - "not uptodate"

On Tue, Sep 1, 2009 at 8:46 AM, <david.hagood@gmail.com> wrote:

Show 28 quoted lines

> I am having a problem trying to support my poor, deluded cow-orkers who
> use Windows and need to use GIT.
>
> The scenario goes something like this:
>
> They have a local repo, they have changes on their branch, they are
> staging a commit to the master branch on their local.
>
> They do a "git merge" and the merge has conflicts. They need to undo the
> merge, so they do a "git reset --hard".
>
> From that point onward, if they try to access the origin repository (e.g.
> "git pull") they get the error message
>
> Error: Entry "Some file name" not uptodate: cannot merge.
>
> We've tried "git reset --hard; git pull ." We've tried "git reset --hard;
> git checkout -f master". Neither seems to fix this.
>
> We Linux users don't see this.
>
> I conjecture it is something to do with DOS's CR/LF line endings (the
> files in question are a type of XML file which ALWAYS have CR/LF endings,
> even under Linux) - perhaps *something* in the GIT processing chain is
> trying to do a CR/LF -> LF conversion, and screwing things up.
>
> Does anybody have any suggestions on what I am doing wrong (Please, not
> "you are using Windows")?

Yeah I run into the same thing on Windows if somebody accidentally checks in a CRLF file. Do you have core.autocrlf on? If you do, I think the problem is that it's going to try to convert the line endings on every checkout/etc, but since the file is already CRLF (not LF as is normally in the repository), it's going to make the file look different every time.

It seems like you want core.autocrlf to be false or you want a .gitattributes file to override it on a per-file basis for the files you know are CRLF (i.e. the ones that are CRLF even on the Linux side).

david.hagood@gmail.com· Sep 1, 2009, 18:25 UTC · re: skillzero@gmail.com · lore

Re: Problems with GIT under Windows - "not uptodate"

> It seems like you want core.autocrlf to be false or you want a
> .gitattributes file to override it on a per-file basis for the files
> you know are CRLF (i.e. the ones that are CRLF even on the Linux
> side).

That's what I've been leaning toward: a .gitattributes in that directory like this:

*.xml -crlf diff merge

Does that sound reasonable?