Package: git Version: 1:2.18.0~rc2-1 Severity: serious Justification: breaks dgit test suite, breaks existing attempts not to corrupt data
Firstly, apologies for filing this bug as RC. I wanted to prevent the new git migrating. It breaks the dgit autopkgtest. For reasons I don't understand, ci.debian.net thinks the dgit autopkgtest `always failed' even though it passes just fine in testing. So britney has reduced the migration delay to a mere 2 days, IMO wrongly. Can we please keep this bug as RC for a little while at least while we decide what to do about it ? So, on to the actual problem: Looking at the manpage for gitattributes(7) it mentions a new attribute working-tree-encoding which affects the way files are checked in and out. dgit and similar workflows need to disable this attribute, because they require that git trees and source packages correspond, which cannot be achieved if working trees made from source packages are not identical to git trees once committed. In #851679 I requested a way to disable all checkout-affecting gitattributes. This has not yet been done AFAICT. In lieu of that, dgit's test suite has a specific test to spot when new attributes are introduced. It tries enabling them and seeing if things go wrong. And indeed, that test has now tripped. (It failed, in fact, simply because some of the values it attempted to set the unknown working-tree-encoding attribute to were invalid, but IMO the test has done its job.) I think at the very least I will need to update dgit to disable working-tree-encoding as well. I think the new git should probably have a Breaks against the older dgit. A proper fix for #851679 would stop this happening next time a new gitattribute is introduced. References: Failing test log https://ci.debian.net/data/autopkgtest/testing/amd64/d/dgit/473624/log.gz Explanation of why dgit needs to disable things https://manpages.debian.org/stretch/dgit/dgit.7.en.html#GITATTRIBUTES Thanks for your attention and forbearance, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
