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