On 2019-12-18 at 11:10:27, 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.

I'm not sure this syncs up with your statements below.  Typically,
programs that do editing of text files either (a) write the line endings
that the file started out with or (b) write the system line endings.  If
you set the appropriate files with the `text` attribute in
`.gitattributes` (or use `* text=auto` if appropriate), then Git will
always write in the system line endings and convert internally to LF,
and programs that do either (a) or (b) will work.

Yet it sounds like you have development tools that don't do either (a)
or (b): they write in some fixed line ending, and therefore care very
much which line ending is being used.  In such a case, you could
write (for example) `*.yaml text eol=crlf` (or `eol=lf`) if you always
want them to do that and Git will convert to those line endings and
store in LF.

If the problem is text editor settings, you can use a `.editorconfig`
file, which is a cross-platform text editor configuration that can
specify line endings.  Most text editors can be configured to honor such
settings, although it may require a plugin.

If your problem is a shared Windows / Linux environment like WSL, you
can set `core.eol` to `crlf` in the repository and things will work.  If
you need settings like this, you can even set them up appropriately for
the system using a make target or bootstrap script so you don't need to
do that by hand on each system.

If you do this, then your tools will write the same line endings as are
checked out, and files won't appear modified.  You can see how Git
itself uses this to set up files appropriately for different systems.

The only case this wouldn't work is if the tools wrote some random line
endings depending on an attribute other than the OS they're on, or if
you had multiple tools doing different things.  If that's really your
problem, then yes, you'd need a new Git feature.  It is of course
possible to use a filter to strip out all carriage returns, but that
doesn't prevent Git from showing the file as being modified.

What I've proposed, of course, requires some setup work and
configuration.  It isn't trivial, but it does work for a lot of projects
already.

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

I'm not sure how such a feature would interact with how Git operates
when it re-reads the index.  It isn't 100% clear to me when data is
filtered through various text filters such as EOL filters.  All the
filtering I've used is one-to-one, and therefore any modification of the
file contents necessarily means that the indexed contents have changed.

If Git does apply such filters when refreshing the index (such as
happens before `git status`), then such a feature would be relatively
easy to implement, although you'd incur a performance penalty when
changing the EOL of a file, even if the file were otherwise identical.
I suspect it would make the most sense as an additional value for
`core.autocrlf`.

If Git doesn't apply those filters, then there really isn't a way to do
what you want without fundamentally changing the characteristics of how
Git operates on the index, since it would still show files as modified.

Maybe someone else can comment on the feasibility of this better than I
can.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204