On Wed, 6 Apr 2016 02:35:09 -0700 (PDT)
Craig Street <craig.str...@gmail.com> wrote:

(The original text was slightly rearranged by me.)

> I have a .sh file that was accidentally committed with CRLF from a
> Windows machine
> I have config set as follows
> core.autocrlf=true

This setting alone should not do anything to your .sh file because if
it sees CRLF line endings in the repository, it does not apply any
normalization when checking that file out to the work tree.

> and also a gitattributes file specified which has
> *.sh text eol=lf

This setting, as I understand it, should have normalized the file.

What happens if you force checking out of that file?

Like with

  $ rm path/to/that/file.sh
  $ git checkout -- path/to/that/file.sh


> When I clone the repo from Linux, and examine this file in hex, it
> clearly still has CRLF line endings despite the config.

Are you sure this is not the case of the mixed line endings?
Git only considers some 512 (or so) first bytes of the file to classify
it as text or binary and detect the line endings, and I've personally
saw files saved from Microsoft Visual Studio which contained mixed line
endings [*], so it indeed might be the case.

In either case, you'd have to normalize the file in the repository
anyway, so I'd fix its line endings using a capable text editor or some
other tool (like `sed` or `tr`) and then committed it back.

[*] To be precise, I suppse the file wasn't actually mangled by MSVS
    but rather by applying something like `git checkout --patch ...` 
    to that file, but MSVS was happy to work with that file, opening
    and saving it back.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to