(Replying in the bug as that seems more apposite:) Firstly, I reread gitattributes(5) and there is a concept of a `builtin macro'. (Not sure if that was there when I filed #851679; I do ask for a `git-defined macro attribute'.)
I think what I am asking for in this bug report is a builtin macro attribute that disables all checkin/checkout attributes, including all future ones. (In the Subject of this report I wrote "checkout-affecting", but of I mean checkin-affecting ones too.) (I think it would also be nice to have a builtin macro attribute that disables all import/export attributes too - but that is not strictly necessary to avoid the kind of lossage we have right now with dgit and the new git.) Jonathan Nieder writes in #901897: > [Ian Jackson] > > 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. > > I think you're saying that attributes like "text" are forbidden in > dgit packages because dgit wants to compare the content of the working > directory to the tracked content without using Git for that. Am I > understanding correctly? Not quite. Firstly it's not *packages* that are affected. dgit needs to be able to work with nonconsenting packages or git branches, including source packages in the actual Debian archive which contain .gitattributes files. So the change needs to be made in particular *clones*. dgit's design principle is that the git tree object is identical to the result of dpkg-source -x (minus any .pc directory). These git branches are published. Obviously they have to not depend on gitattributes, what version of git is being used, the user's git config, etc. So such attributes must be disabled *when dgit operations are being performed*, because dgit's own git operations might get wrong answers otherwise. But it also means that such attributes must be disabled *in the user's tree* because otherwise they will cause terrific trouble. The thing the user gets from `git checkout' would not be the same as dpkg-source -x and might not even be buildable. Attempts to apply patches might fail. etc. dgit doesn't just compare things. It imports and exports. Much of dgit is a sophisticated bidirectional translator between source packages and git branches, and a converter between git branches of various different forms and fixer-upper of anomalous states which can occur with dpkg-source `3.0 (quilt)'. > Strictly speaking, since users can configure filters that run > arbitrary commands (see "filter" in gitattributes(5)), that's true, > but the transformations are meant to produce a canonical "smudged" > form in the worktree and a canonical "clean" form in the repository. I don't think that is sufficiently robust. And the functionality implemented by checkin/checkout .gitattributes is not needed in the context of dgit. dpkg-source doesn't have that feature which means that Debian source code doesn't need those features. > Sorry I missed bug#851679 before. We can discuss this more there. > Perhaps some command like "git archive" would work better than "git > checkout" for this use. dgit does a lot more than `git checkout'. `git add -Af .' and `git am' and lots of other things. dgit likes to work in git where it can because git is better at many of these operations than copying files etc. Thanks for your attention. 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.
