> I'm not sure this syncs up with your statements below...[snip] Unfortunately it is the latter case where certain dev apps, or plugins within dev apps, that can occasionally write incorrect line endings. We don't have configurable control over these things unfortunately. If I widen the scope to all the scenarios you presented though - My feature request could still have value as another way to alleviate the pressure EOL changes create on a git repo. I would agree that it would be best to solve the problem at its source where possible, but it is sometimes not possible. > I'm not sure how such a feature would interact with how Git operates when it re-reads the index... AFAIK git status does not filter the results, as that would push writes to files (I think?) when the user wouldn't expect it to. So it makes sense that actions such as git status are unaffected by text/crlf options. I agree the additional cost to run a filter or similar action with git status would be a cause for concern, but maybe an optional and acceptable trade-off for the pain it alleviates elsewhere. I do not know the underlying way git works either, but I suspect it would have to be a 3rd test after sha1 & oid against the files that come out of git status. I'm guessing that is an area of git that has little configurability and therefore very difficult to make changes to. :/ Regards, Scott Richmond. Director, Producer, Programmer Brightrock Games T: 07480795661 On Fri, Dec 20, 2019 at 3:03 AM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > 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
