>> - Martin Geisler also proposes that there is a section >> [repository] >> native = <conversionmode> >> I personally feel YAGNI; it should only support LF (adding such >> a feature later may be considered) > > Do you mean what native is in the repo or what it should be considered > on the user's machine? The former. > If it's the former then I actually like it as > it means a clone doesn't need to do anything special when 'native' > matches what is expected in the repo while a commit still does its EOL > validation. But the same would be true if the repo format would be always LF: when "native" matches (which would then be on Unix), the extension would *still* have to do nothing but validation. > I still think we need to have a server-side block which > rejects commits that messes up the line-endings so people can fix > them. Certainly. > Shouldn't mess up 'blame' as the messed up line-endings should > only be from their edits. It could be that they had a number of commits that eventually lead to the version that they push; this will also push the intermediate versions. So when you then do a blame, it will tell you that the revision was logged as "fix whitespace", rather than "resolve issue #9743". You are mostly right that the committer name would be the same (except when the committer was pushing some changes pulled from the actual contributor), however, I still see these whitespace-only changes as a complication. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4