On Sat, Sep 5, 2009 at 15:06, "Martin v. Löwis"<martin@v.loewis.de> wrote:
- 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.
Right, but I am just thinking about how we specify in .hgeols what the repository is expected to be as this extension might work out nicely for other projects who prefer CLRF as their repo-native line ending.
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".
Yep.
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.
It's unfortunate, but I see it as a rare occurrence as it would only happen if someone got sloppy. And it should typically get caught client-side before the commit ever occurs, minimizing the whitespace-only commits even more. -Brett