I agree release distributions should have consistent end-of-line
handling, but I think this is a separate problem/decision from how we
deal with end-of-lines in git. Release distros are produced once, so we
can pick single eol-format. Git repositories, on the other hand, are
used and modified by multiple developers on multiple systems. We have
to a solution that works for everyone, which I believe means translating
between windows and proper eols during checkout and commit. Github have
come up with a convention that works, so why not take advantage of
their vast experience with git?
--
Regards,
Igor
On 2014-10-12, 9:32, Robert Scholte wrote:
This is probably bigger then just git.
We discovered that right now the release distributions are actually OS
specific. If I would do a release, the EOLs are Windows based, where as
releases of most others are Unix based.
This was exposed by some checkstyle rules: checking out from subversion
translates the EOL to native, whereas the distribution zip is not.
Verifying the source-release.zip with a different OS made checkstyle
report several errors.
I think this should be consistent for every distribution. There are two
options I can think of: always use the same EOL, no matter the OS
(though I'm not sure about the consequences) or when generating the
-source-release.zip the EOL should be changed to the preferred one.
thanks,
Robert
Op Sun, 12 Oct 2014 14:53:32 +0200 schreef Igor Fedorenko
<[email protected]>:
What EOL handling are we expected to use for Maven git repositories? I
don't recall this was discussed before, but this commit [1] stands out
from the rest. I usually follow github recommendation [2], so I wonder
if we can adopt the same for Maven work. Any thoughts?
[1]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=8506c638c6a21a902e85831185e2121d8ddcb55b
[2] https://help.github.com/articles/dealing-with-line-endings/
--
Regards,
Igor
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
