Author Topic: pak96.comic git mirror, CRLF trouble  (Read 1609 times)

0 Members and 1 Guest are viewing this topic.

Offline sdog

pak96.comic git mirror, CRLF trouble
« on: April 12, 2014, 03:54:27 AM »
Hello,

a little while ago a new .gitattributes file was added to the sourceforge SVN. It caused me a few complications on the side of a git mirror, as the files in the svn are mostly with windows CRLF line endings. Previously this was ignored, with the new .gitattributes git didn't anymore. Sine the way from svn to git is through rebasing the git repo on the new commits/revisions from the svn this causes trouble everytime. I haven't found a working sollution yet.

Well, i'd suggest to change the .gitattributes on the svn to this version. But only after someone who understands more of it has looked at it. I'm very close to giving all up though.

.gitattributes
Code: [Select]
# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

# Explicitly declare text files we want to always be normalized and converted
# to native line endings on checkout.
*.dat text
*.md text

# Declare files that will always have CRLF line endings on checkout.
*.bat text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.PNG binary
gg


ps.: just had a new idea of looking into core.autcrlf. Perhaps setting it to ignore CRLF diffs before cloning the repo, would override the .gitattributes file, and keep the git mirror with windows line endings.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2594
  • Total likes: 290
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: pak96.comic git mirror, CRLF trouble
« Reply #1 on: April 12, 2014, 09:19:35 PM »
If this fails I guess it's better to "reset" the SVN, even if it means by hand.

Offline sdog

Re: pak96.comic git mirror, CRLF trouble
« Reply #2 on: April 12, 2014, 09:55:15 PM »
I think there ought to be a way to do this without changed on the svn side. We just want to mirror with git. It's not worth to risk any thing on the svn side, especially since so many other paks are there.