That's the way this used to be; but they actually .solved. this
problem with the .gitattributes approach, so all we need to do is add
xml and properties files.
We just need to find out which of these should be added (from maven plugins):
Kristians-MacBook-Pro:maven-plugins kristian$ find . -type
I am no git expert, but I believe proper text-vs-binary classification
is only part of the solution. Git still needs to know what format to use
in the repository and what format to use for the checkout. At least this
was the case when I started using git, maybe modern versions are smarter
about th
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 m
Ah ! The answer is that we don't leave it to the user to handle line endings.
I have added .gitattributes files to all our git repos, which
basically dictate how line endings should be handled.
The thing is; it does not contain "xml" files. This is the one I have added:
*.java text diff=java
*
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
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.apac
