Preserve line endings during x-revision bumping

[nponeccop]

snap package currently has different line endings in cabal unpack and cabal unpack --pristine, which I find nasty as it makes automation harder.

I'm not sure where to report the problem, and I'm not aware of the design of this x-revision patching to suggest a fix. I understand it's a minor problem, but now line conversion is needed just to see a nice diff between two .cabal versions. It could be nice if hackage could prevent such breakage.

$ diff -u src/snap-0.13.3.2/snap.cabal \
    <(cat ../patched-snap/snap.cabal | tr -d '\r')
--- src/snap-0.13.3.2/snap.cabal    2014-11-25 06:32:06.000000000 +0200
+++ /dev/fd/63  2015-01-23 10:45:35.228471993 +0200
@@ -1,5 +1,6 @@
 name:           snap
 version:        0.13.3.2
+x-revision: 1
 synopsis:       Top-level package for the Snap Web Framework
 description:
     This is the top-level package for the official Snap Framework libraries.
@@ -186,7 +187,7 @@
   else
     build-depends:
       base                      >= 4.4      && < 5,
-      lens                      >= 3.7.6    && < 4.7
+      lens                      >= 3.7.6    && < 4.8

   extensions:
     BangPatterns,

Without the conversion diff shows all lines differ.

[hvr]

Just wondering, where does this cause problems for you? Also I'm curious about which kind of automation you're performing.

[nponeccop]

I'm building an automation layer on top of https://github.com/magthe/cblrepo to make it humanly possible to maintain thousands of packages instead of mere 300. The cblrepo system of patches degrades over time, so I parse patches to fix them. And radical changing of line endings is, well, just too radical as it immediately invalidates all lines in the old patch.

It is this type of patching of patches I'm trying to automate.

[dcoutts]

Hmm. This could be a little tricky. The browser probably sends us the result with line endings all one way round. We'd have to have some pass that goes through line by line and where the only change is the line ending, switch it back. But matching them up gets harder for the bits around the line where we are actually editing it.

[Blaisorblade]

Sorry to butt in, ended up here after observing the same curious behavior.
Couldn't one just canonicalize line endings through (an Haskell version of) dos2unix? The cabal files are from tarballs, but they're being edited anyway, so there's a place for this canonicalization.
This would change existing line endings, but maybe that's enough?

Alternatively, I wonder why can't @nponeccop do this canonicalization on his end—he already showed an appropriate command line. Alternatively, could this have been fixed in archhaskell/cblrepo#40 and archhaskell/cblrepo@3dfca74?

[snoyberg]

Note that this problem affected all-cabal-files, and was reported by @peti. See: commercialhaskell/all-cabal-files#11. After asking for feedback on Twitter, we decided to enable git config --global core.autocrlf input to canonicalize the .cabal files (which honestly is something I'm still on the fence about being a good idea).