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@xxxxxx> 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
