On 18/06/2019 11:00, sebb wrote:
On Tue, 18 Jun 2019 at 10:40, Alex Herbert <alex.d.herb...@gmail.com> wrote:
On 18/06/2019 09:55, sebb wrote:
On Tue, 18 Jun 2019 at 08:15, Julian Reschke <julian.resc...@gmx.de> wrote:
On 17.06.2019 23:26, sebb wrote:
Most of the files in my clone of codec have LF endings, however a few are CRLF:
./README.md
./src/assembly/bin.xml
./src/assembly/src.xml
./src/changes/changes.xml
./src/main/java/org/apache/commons/codec/cli/Digest.java
./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
This causes spurious differences when the files are updated.
Can these files be easily fixed without causing huge diffs to be generated?
Also, is there any way to prevent such files being committed to the repo?
S.
If svn:eol-style is set to "native", it shouldn't matter. I think this
can be defaulted for newly added files.
Thanks, but this is Git, not SVN.
In Jackrabbit, I regularly run a script to spot new files missing the
property.
Are you willing to share the script?
This was recently a problem in [statistics]. It was fixed using a
.gitattributes file [1] containing:
* text=auto
You can fix all the existing files following the steps detailed on the
git documentation:
$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"
Thanks, though that did not pick up two of the files.
Oh dear.
When I tried this locally it misses from your list:
./src/changes/changes.xml
./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
Those files are also ignored on my machine (linux) by dos2unix. They are
not found by any of the following [1]:
$ grep -IUr --color "^M" src
$ find src -type f | xargs file | grep CRLF
$ grep -IUlr $'\r' src
So are they a problem?
However it looks like the commit message will show huge diffs for each file.
Is that unavoidable?
The diff is done line-by-line. So if each line changes then it is a big
diff. I don't know a way around that.
The alternative would be to leave the .gitattributes file and not commit
the normalised files. The next time someone commits each of the
offending files the normalisation will occur as git sends it back to the
repo. So this just delays the big diff. At least if it all done at once
then it makes more sense and avoids the issue of a big diff occurring
some time in the future and someone has to figure it out all over again.
[1]
https://stackoverflow.com/questions/73833/how-do-you-search-for-files-containing-dos-line-endings-crlf-with-grep-on-linu
[1] https://git-scm.com/docs/gitattributes
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
