www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - driver/tool.cpp

reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
Weird issue after pulling in latest LDC git master.

git is reporting that driver/tool.cpp has been changed.  The 
checkout and reset commands don't alter this.  git difftool -t 
meld reports that the file is actually unchanged (!).

Anyone have any clue what's behind this?  I ran git submodule 
update but I don't think this is submodule code ... ?

Thanks & best wishes,

     -- Joe
Jul 08 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 8 July 2014 at 19:41:50 UTC, Joseph Rushton Wakeling 
wrote:

 git is reporting that driver/tool.cpp has been changed.  The 
 checkout and reset commands don't alter this.  git difftool -t 
 meld reports that the file is actually unchanged (!).


Maybe you accidentally modified the file permissions, although 
this should show up in git diff? Or did you change your autocrlf 
settings? In any case, git reset --hard HEAD should remove all 
local modifications (be careful!) and reset the working tree to 
the latest commit.

Best,
David
Jul 08 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 8 July 2014 at 19:44:46 UTC, David Nadlinger wrote:

 Maybe you accidentally modified the file permissions, although 
 this should show up in git diff? Or did you change your 
 autocrlf settings? In any case, git reset --hard HEAD should 
 remove all local modifications (be careful!) and reset the 
 working tree to the latest commit.


Already tried reset --hard HEAD to no avail.  It was my second 
thought after git checkout. :-(

I have not deliberately touched any file in the repo, but I did 
switch from a checkout of the merge-2.065 branch to master 
recently.  The problem file emerged when I pulled from master.  
Don't know if that has any relevance.

Oh, and I'm on Ubuntu 14.04 with git 1.9.1.

There's some stuff on StackOverflow about how this can show up on 
Windows if the repo contains files that whose names are 
equivalent if case is not considered, but that's obviously not 
the case on case-sensitive Linux.
Jul 08 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 8 July 2014 at 19:51:12 UTC, Joseph Rushton Wakeling 
wrote:

 There's some stuff on StackOverflow about how this can show up 
 on Windows if the repo contains files that whose names are 
 equivalent if case is not considered, but that's obviously not 
 the case on case-sensitive Linux.


Hmm, looks like it's a line-ending thing.  Did someone edit this 
file in a Windows editor that puts Windows line endings on 
everything?

git diff -w reports:

warning: CRLF will be replaced by LF in driver/tool.cpp.
The file will have its original line endings in your working 
directory.
Jul 08 2014
next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 8 July 2014 at 19:53:41 UTC, Joseph Rushton Wakeling 
wrote:

 On Tuesday, 8 July 2014 at 19:51:12 UTC, Joseph Rushton 
 Wakeling wrote:

 There's some stuff on StackOverflow about how this can show up 
 on Windows if the repo contains files that whose names are 
 equivalent if case is not considered, but that's obviously not 
 the case on case-sensitive Linux.


 Hmm, looks like it's a line-ending thing.  Did someone edit 
 this file in a Windows editor that puts Windows line endings on 
 everything?

 git diff -w reports:

 warning: CRLF will be replaced by LF in driver/tool.cpp.
 The file will have its original line endings in your working 
 directory.


Just for reference: I haven't got core.autocrlf set in either my 
global .gitconfig or in ldc's .git/config.
Jul 08 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 8 July 2014 at 19:53:41 UTC, Joseph Rushton Wakeling 
wrote:

 Hmm, looks like it's a line-ending thing.  Did someone edit 
 this file in a Windows editor that puts Windows line endings on 
 everything?


Seems like this file had mixed line endings, should be fixed in 
master now.

It's still rather strange behavior from Git, though.

Best,
David
Jul 08 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 8 July 2014 at 20:05:26 UTC, David Nadlinger wrote:

 Seems like this file had mixed line endings, should be fixed in 
 master now.


Thanks!

This was slightly nasty to resolve, because of course the 
"changed" file meant I couldn't just pull; I had to use

git fetch
git reset --hard origin/master

to check out the patch that fixed it.


 It's still rather strange behavior from Git, though.


Yea, not nice.  Particularly that you seemingly can't check out 
the file to its original form (though maybe I missed an option to 
git checkout somewhere).

Thanks again for the fix!
Jul 08 2014
parent reply Brad Roberts via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 7/8/14, 1:53 PM, Joseph Rushton Wakeling via digitalmars-d-ldc wrote:

 On Tuesday, 8 July 2014 at 20:05:26 UTC, David Nadlinger wrote:

 Seems like this file had mixed line endings, should be fixed in master now.


 Thanks!

 This was slightly nasty to resolve, because of course the "changed" file meant
I couldn't just pull;
 I had to use

 git fetch
 git reset --hard origin/master

 to check out the patch that fixed it.


 It's still rather strange behavior from Git, though.


 Yea, not nice.  Particularly that you seemingly can't check out the file to
its original form
 (though maybe I missed an option to git checkout somewhere).

 Thanks again for the fix!



Wouldn't this do it?

   rm <file>
   git checkout <file>
Jul 08 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 8 July 2014 at 21:00:39 UTC, Brad Roberts via 
digitalmars-d-ldc wrote:

 Wouldn't this do it?

   rm <file>
   git checkout <file>


I don't think so.  The point is that git always checks the file 
out with CRLF endings even though internally it's stored with LF. 
  That's why even a reset --hard HEAD won't do it.
Jul 09 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Joseph Rushton Wakeling"  wrote in message 
news:enkxayckyjvghzwwyghz forum.dlang.org...


 I don't think so.  The point is that git always checks the file out with 
 CRLF endings even though internally it's stored with LF. That's why even a 
 reset --hard HEAD won't do it.


This is why I always disable autocrlf.  I'd rather my line endings be 
'wrong' than magically change.
Jul 10 2014