Hi, On Wed, Apr 27, 2022 at 07:34:13PM +0200, Christoph Berg wrote: > > Quite a lot of packages ship .gitattributes in their tarballs, leading > > to strange effects while building packages and, most importantly, > > leading to the imports not creating Git trees identical to the tarballs. > > rdkit was also affected by this. I ended up doing "gbp import-orig > --filter .gitattributes $tarball", but this will have to be remembered > on every future tarball import.
You can set the filter in `d/gbp.conf` to not forget (the defusing of attributes with newer gbp should also work but filtering is likely better as you don't have to worry about new git attributes being added in the future). Cheers, -- Guido > > https://salsa.debian.org/debichem-team/rdkit/-/commit/6e8b2f28c07ea515be9549b92e975acf9d25c99b > > > A remedy to this would be git-buildpackage creating .git/info/attributes > > with this content: > > > > * -text -eol -crlf -ident -filter -working-tree-encoding > > > > This disables any transformation of the version-controlled file. > > > > Even better would be if gbp created the Git trees manually using > > low-level Git commands which don’t take Git attributes into account. > > Is that enough? Any later git command will still mangle the files if > that .gitattributes file is still present. > > Maybe it's not a problem since only files in debian/ should be > touched, but I guess there might still be weird problems with files in > debian/patches/ with non-native EOLs. > > Christoph
