What is the workaround exactly? Removing Windows line endings on files as they're touched/as needed by package maintainers?
IMHO adding a single commit to our repo that will remove all Carriage Returns has some drawbacks.
The most important is that it will render the "git blame" command useless and that will make the repo bigger.
Wouldn't this flag from man git-blame
Code: Select all
Ignore whitespace when comparing the parent’s version and the child’s to find where the lines came from.
IMO getting rid of Windows line endings piecemeal is not a great solution. You still end up with the same issue of a big commit making the revision history less useful. The alternative is a history-rewriting change that will mess up people's cloned repos, forks, etc. This will have some pain, but so does ripping off a bandaid. There are tools specifically for this, see git-filter-branch
The number of people who are actively working off & contributing from cloned repos is probably pretty manageable, and as long as a clear path for getting through it (arrived by testing, which I can help with) is included with the announcement that it's going to happen, it should be fine.
I'm not sure what runtime path issues jobermayr is referring to, but other concerns like conforming to the filesystem hierarchy and mixed line endings are valid and I think if they are reasonably fixable they should be. (BTW there's 1.34 million hits for "mixed line endings issues" on Google for me.)