>> - 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com