Re: Ability to ignore EOL changes for certain projects

["Torsten Bögershausen" <tboegi@web.de>]

Scott, please avoid top-posting in this list, see my answers at the end.

> On Wed, Dec 18, 2019 at 7:27 PM Torsten Bögershausen <tboegi@web.de> wrote:
> >
> > On Wed, Dec 18, 2019 at 11:10:27AM +0000, Scott Richmond wrote:
> > > The Problem Domain
> > > In certain dev environments (Unity3D projects) there is (AFAIK) an
> > > unsolvable problem where some files are often modified with line
> > > endings that aren't the native system or not the committed line
> > > endings for that file. Secondarily, in this case line endings don't
> > > matter - Nothing in the dev environment "cares" which kind of line
> > > ending is used.
> > >
> > > The Problem
> > > Git always cares about EOL. Git has options to transparently modify
> > > EOLs when files are checked in or out. However it is not possible to
> > > tell Git to ignore EOLs in other commands:
> > > Git status shows the file modified.
> > > Merging/Pulling has to care because it can't merge with a modified
> > > working tree. Which means the user has to care - They have to either
> > > stash the EOL changes or wipe them out. Sometimes, if the user has a
> > > particular app running, it may automatically reload that file and
> > > recreate the modified EOL changes, causing an endless loop. This
> > > problem is often made unclear to the user how to solve, especially if
> > > they aren't domain experts.
> > >
> > > To be clear, in this particular dev environment, I can say with
> > > confidence that this particular issue is a major and common pain point
> > > for users. It is made worse as many users in this environment aren't
> > > programmers by trade and aren't domain experts in version control. I
> > > also believe this environment is becoming a non-trivial portion of the
> > > Git userbase and it would be worthwhile looking into resolving.
> > >
> > > Solution Request
> > > It would be fantastic if we could tell Git to stop caring about EOL
> > > changes on a per-repo basis, with the effective output being that git
> > > status shouldn't show changes for files with differing EOLs.
> > >
> > > I'm experienced with Git, though I am not expert enough to consider
> > > creating such a change myself - It is unclear to me just how
> > > complicated a change may be. However maybe I could look into it if it
> > > was made clear that this improvement is possible and has no serious
> > > side effects.
> >
> > Hej Scott,
> > I think that you problem can be solved.
> > For each repository, you can tell Git to ignore the line endings,
> > CRLF vs LF.
> >
> > If you start with a fresh repo,
> > you can do something like:
> >
> > echo "* text=auto" >.gitattributes
> > git add .gitattributes
> > git commit -m "Add .gitattributes"
> >
> > For existing repos, we need to take another step:
> >
> > echo "* text=auto" >.gitattributes
> > git add .gitattributes
> > git add  --renormlize .
> > git commit -m "Add .gitattributes"
> >
> > More information can be found e.g. here:
> > https://git-scm.com/docs/git-add
> >
> > Once you done that, you can merge branches
> > into the master branch with help of the renormalize
> >
> > git merge -X renormalze branch-name
> >
> > See even here:
> > https://git-scm.com/docs/git-merge
> >
> >
> > This is just a (too) short introduction, I hope that it
> > helps and that you find the time to dig somewhat deeper into
> > the documentation.
> >
> > Other developers have that problem as well, you are not alone.
> >
> > If you have a public repo, I could help with one example.
> >
> >
> > >
> > > Regards,
> > >
> > > Scott Richmond.
> > >   Director, Producer, Programmer
> > >   Brightrock Games
> > >   T: 07480795661
On Wed, Dec 18, 2019 at 09:33:32PM +0000, Scott Richmond wrote:
> Hey Torsten,
>
> Thanks for the reply!
>
> Correct me if am wrong, but those steps don't tell git to "ignore"
> line endings. That just causes git to check all text files in and out
> with a specific EOL type (Either automatically chosen, or not). If an
> app in the dev env changes a files' EOL to something else, git will
> notice the change locally.
>
> Regards,
>
> Scott Richmond.
>   Director, Producer, Programmer
>   Brightrock Games
>   T: 07480795661
>

Hej Scott,

I am not sure whether I understand your question correctly.
So I set up a little test, to illustrate things better.


user@linux:/tmp/EOLtest $ git init
Initialized empty Git repository in /tmp/EOLtest/.git/
user@linux:/tmp/EOLtest $ printf "Line1\r\nLine2\r\n" >file
user@linux:/tmp/EOLtest $ git add file
user@linux:/tmp/EOLtest $ git commit -m "add file with CRLF"
[master (root-commit) 0e4d1df] add file with CRLF
 1 file changed, 2 insertions(+)
  create mode 100644 file

user@linux:/tmp/EOLtest $ printf "Line1\nLine2\n" >file
user@linux:/tmp/EOLtest $ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   file

no changes added to commit (use "git add" and/or "git commit -a")
user@linux:/tmp/EOLtest $ git diff
diff --git a/file b/file
index 4aa551d..ac2dd81 100644
--- a/file
+++ b/file
@@ -1,2 +1,2 @@
-Line1
-Line2
+Line1
+Line2

user@linux:/tmp/EOLtest $ echo "* text=auto" >.gitattributes
user@linux:/tmp/EOLtest $ git add --renormalize .
user@linux:/tmp/EOLtest $ git commit -m "Normalize the repo"
[master b41136d] Normalize the repo
 1 file changed, 2 insertions(+), 2 deletions(-)
 user@linux:/tmp/EOLtest $

user@linux:/tmp/EOLtest $ printf "Line1\r\nLine2\r\n" >file
user@linux:/tmp/EOLtest $ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   file

user@linux:/tmp/EOLtest $ git diff
warning: CRLF will be replaced by LF in file.
The file will have its original line endings in your working directory

#############################
No, at this point, I am surprised myself.
"file" is reported as "modified", but it should not be modified, right?
Is that the problem, that you have ?


We can fix it, by running:

user@linux:/tmp/EOLtest $ git add file
user@linux:/tmp/EOLtest $ git status
On branch master
nothing to commit, working tree clean

But I still think, that this "modified" is unexpected,
and a (possible) bug in Git, thanks for reporting.

Which Git version do you use ?
Is this test script a description of you problem ?