Re: gbp import-orig maybe ignores .gitattributes?

[Gianfranco Costamagna <costamagnagianfranco@yahoo.it>]

Hi,

I have *never* been able to fix such issues, sometimes a git reset --hard commitid and git pull worked, sometimes else
a .gitattributes file helped

or removing the files and manually untarring the new release.
Git for some reasons doesn't take changing newlines as differences (not sure)
(look for boinc.git on alioth and the .gitattributes file)
https://help.github.com/articles/dealing-with-line-endings/
http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git
http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
http://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat
http://stackoverflow.com/questions/9976986/force-lf-eol-in-git-repo-and-working-copy


hope this helps!

have a nice hacking,

G.




Il Venerdì 25 Marzo 2016 21:02, Peter Spiess-Knafl <dev@spiessknafl.at> ha scritto:
Hi!

I am currently having troubles packaging the new upstream version of
libjsoncpp.

https://github.com/open-source-parsers/jsoncpp

I downloaded the newest upstream version using uscan and used gbp
import-orig to import the downloaded tarball.

Now I recognize that there are some Visual Studio files in it which have
CRLF lineendings in the tarball but LF line endings in the checkout
working directory.

dpkg-source complains during package built that the working directory
does not comply with the downloaded tarball.

Upstream does provide a .gitattributes file which takes care of this
problem. However gbp import-orig somehow seems to ignore this.

Can someone give me a hint what I am doing wrong?


Thank you and greetings
Peter