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
Attachment:
signature.asc
Description: PGP signature
