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

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

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.

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.

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.

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

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!

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>

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.

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