Re: Ability to ignore EOL changes for certain projects

[Scott Richmond <scott@brightrockgames.com>]

> If I recall previous discussions, part of the issue is determining what
the alternate abuse cases are, such as lone CRs, or alternate character
sets to the 'pure' utf-8.
In this dev env, I would be surprised if any CR type makes a
difference. But I could be wrong.
If that is indeed one of the reasons why previous discussions broke
down, maybe that could be a configurable option in the feature
improvement.

> Does the environment (on any of the OS's) change the files in the background, such that the file time stamps will indicate a modification?
I would imagine the file timestamps do get updated yes. Though I'd
have to do some research to confirm it.

If indeed this isn't a bug (As Torsten suspects), then I suppose what
I am asking for is a feature improvement to perform a further check
after sha1/iod to confirm if the changes are only between CR types?

Regards,

Scott Richmond.
  Director, Producer, Programmer
  Brightrock Games
  T: 07480795661
On Wed, Dec 18, 2019 at 10:35 PM Philip Oakley <philipoakley@iee.email> wrote:
>
> On 18/12/2019 21:33, 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.
>
> A broader question is "how does the dev environment handle lone `CR`
> characters? are they also considered as EOLs?"
>
> If I recall previous discussions, part of the issue is determining what
> the alternate abuse cases are, such as lone CRs, or alternate character
> sets to the 'pure' utf-8.
>
> You will still have the difficulty of how `identicality` is determined,
> which currently uses the sha1/oid value. In essence you need a way of
> ensuring that all checkins are always of one defined EOL, but then need
> git to have a broader allowance of changed EOL values (including no lone
> CRs that are not EOL, etc).
>
> Does the environment (on any of the OS's) change the files in the
> background, such that the file time stamps will indicate a modification?
>
> Philip
>
> > Regards,
> >
> > Scott Richmond.
> >   Director, Producer, Programmer
> >   Brightrock Games
> >   T: 07480795661
> >
> > 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
>