Re: Ability to ignore EOL changes for certain projects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux