-1

Shortend question:

Can I solve my various Git line-ending cross-platform conversion problems by using .gitattributes and setting the problematic files to binary? I have no control over the repo or the users settings.

Also: is CRLF still needed at-all for web-oriented Windows development? Most tools have either auto-detection or options to switch mode and seem to work fine with LF-only.

(removed rant)

Note: I already read many (all?) answers about this here on SO, read the help, read the book and burned way too much time on this.

Update:

I'm not looking at this help file and it mentions un-setting text in .gitattributes:

Unset

Unsetting the text attribute on a path tells git not to attempt any end-of-line conversion upon checkin or checkout.

Why both "help.github.com" and "git-scm.com" don't mention this as a possible solutions is beyond me, but the description looks good.

But the github help does mentions it cursory, which is why I think this is what I want.

binary setting is an alias for -text -diff

I'm going to try that, and update if it works out.

Update 2:

It worked! Use *.txt -text in .gitattributes did the trick: no conversions but still diffable and line/char summaries etc)

Community
  • 1
  • 1
Bartvds
  • 3,340
  • 5
  • 30
  • 42
  • 1
    You might want to trim your question a bit, to focus on the specific technical query (forcing everything to be binary). The rest of your question comes across as a rant. – Graham Borland Nov 04 '13 at 15:02
  • @GrahamBorland it was born out of frustration. I pre-pended my ranty original with a shortened version. – Bartvds Nov 04 '13 at 20:08
  • "binary" has a specific meaning in git. In C stdio it means don't do `\n` translations, but in git it means the data isn't text at all, that there's no good way to map it to "lines", whatever they are. – jthill Nov 04 '13 at 20:26
  • @jthill Ok, so I need some text mode, in a way where git does not mess with the newlines, both on commit as well as on checkout. – Bartvds Nov 04 '13 at 20:30

4 Answers4

1

You can configure git to convert CRLF to LF when adding stuff but not the other way round:

git config --global core.autocrlf input

Relevant documentation from git-config(1)

core.autocrlf
Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.

Or a more in-depth explanation in this SO answer: git replacing LF with CRLF

Community
  • 1
  • 1
ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
1

I think that if you turned everything to binary, you're commits wouldn't be line diffs anymore, which would stop git diff, git log --stat or owt like that from working. Your best option is to either ensure that all files are saved as LF, use core.autocrlf input to force all files to be converted to LF or just try a different VCS if it's giving you that much trouble.

wdh
  • 1,612
  • 12
  • 16
  • Using Git is a given, and I cannot force the LF use (high-traffic community repo). But `core.autocrlf input` sounds hopeful. – Bartvds Nov 04 '13 at 20:13
  • Why can everyone push to the repo? If you want to control what people push let them send pull requests and reject them if they introduce crap such as CRLFs – ThiefMaster Nov 04 '13 at 21:03
0

Something you could try, see how it works for you:

git config core.autocrlf false          # no automatic eol munging
git config core.whitespace cr-at-eof    # diff ignores trailing CR
git config branch.<name>.mergeoptions -Xignore-space-at-eol

and it'd probably be good to avoid explicit text attributes in .gitattributes (which force eol conversion on checkout, though the converted version won't be gratuitously checked back in).

See the merge doc for the effects of that branch config, (plus the config docs), it seems to work pretty well for me. Or just specify it manually when trouble hits.

If you have other tools that can't handle mixed or foreign eols you're still going to have to work around their limitations, maybe by putting explicit eol attributes on the files they need. I'd leave that as a per-repo thing myself, it's a local issue that goes away if the tools ever get fixed.

jthill
  • 55,082
  • 5
  • 77
  • 137
0

As I updated in my question: use -text this in .gitattributes to make git teat the file as text but don't do any line conversions. It will still show diffs (and related changes summaries):

*.txt    -text
Bartvds
  • 3,340
  • 5
  • 30
  • 42