CODEWITHSUNDEEP
windowsgit
Arafangion
Arafangion

Reputation: 11910

What line endings are used when writing to the actual git repository?

For a large existing repository that contains inconsistent line endings, and file encodings with ascii and UTF-8 (With BOM)...

The key thing is that the current set of files are fairly inconsistent. They vary in encoding. (Lets ignore UTF-16 for now, although I do have a few of those, too). They vary in line endings from file to file, and they vary in line endings within the files themselves too, although I suspect that most of them are stored with crlf line endings in git.

There are two main issues here:

1) Different people using the same repositories can look at changes, and they see a different set of changes. Sometimes the "whole file" has been changed, because of normalised line endings. Sometimes only a part of the file has been changed. This seems to be mostly dependent on whether or not core.autocrlf has been set to true or false, and also seems influenced by the use of a .gitattributes file.

2) I want all people to be able to submit files to the git repository, without having to pay painful attention to whether their particular git configuration has been set to do crlf conversion, or their text editor, IDE, or whatever tools they decided to use. (As broken as this behaviour can be on windows, we need to live with it...)

The main question is this: How do I be sure that the output shown by 'gitk', 'git diff', 'git show', and the like, are absolutely consistent with respect to the changes shown. I am less concerned about line endings here, and more about ensuring that the 'change' for a given commit is the same change as viewed by all developers. I do not want one person looking at a change, and see "all the lines have changed" (That is, the line endings changed), while another person sees the same change, and says: "three lines have changed".

That said, I want to have confidence in knowing how the line endings are concerned, so I am ultimately asking for how to know what happens with the line endings. If, eg, I specify "eol=crlf" for a given file in .gitattributes, does that mean that the file is committed to git with that setting? And what happens if I check out an earlier version of that file that was committed prior to setting that .gitattributes file?

Upvotes: 3

Views: 341

Answers (2)

Chronial
Chronial

Reputation: 70673

Ok, here’s what’s happening:

First: Diffs always look the same and do not depend on local git configuration. You can try that: git diff HEAD^ HEAD will look the same on all your machines (assuming they have the same HEAD).

But why do the diffs look different on your machines then? Assume you have a file in your repo that looks exactly like this:

two \r\n lines

Checked out will look like this on every machine. But on check in there are two options:

  1. Line ending normalization is on. The file will now be checked in as:

    two \n lines

    and git diff will report that there is going to be a change

  2. Line ending normalization is off. The file will be checked in as:

    two \r\n lines

    and git diff will not report any changes.

Now, how can you make sure that everybody sees the same changes? I would recommend to enable line ending normalization for everyone. To do that create a .gitattributes in the root of your repo with this content:

*   text=auto

And commit this file to every branch. Once everybody has pulled this commit, the diffs will look the same everywhere.

Final note: core.eol does have no effect on this whatsoever. It only changes the line endings in the working directory. git diff does not diff the working directory against the index, but it diffs what would be commited against the index.

Upvotes: 2

jthill
jthill

Reputation: 60275

I assume you'll google "git line endings" to see how to do basic repo setup.

You can't influence anything already committed at all. The only thing you can do is make new commits with any fixed-up file contents you like.

From your comment below, what you're after is being able to completely ignore line-ending differences. See here and here for the best previous stackoverflow answers I could find.

Upvotes: 1

Related Questions