This seems to be best discussed as part of #1079434,
so moving the discussion there:
Simon Josefsson writes ("Bug#1111548: tag2upload service makes .origs with
un-defused gitattributes"):
> If you make dgit not respect .gitattributes,
...
Firstly, dgit has suppressed .gitiattributes since January 2017. That
was eight and a half years ago, and 3 and a half years into dgit's
existence. I made that change as soon as I encountered the problem -
in a package of which I was the maintainer.
As I write earlier in this bug:
When I developed this aspect of dgit, I was thinking of upstreams
who put all manner of surprising things in .gitattributes. For
example, upstream Xen git has a .gitattributes file which encodes
version information in working tree files.
This is the use case you're discussing in your email.
This isn't compatible with dgit's core invariant, which is that the
git tree object is precisely the same as the content of the source
package. (The alternative invariant would be that source package is
identical to content of the working tree *as transformed by
gitattributes* - but the gitattributes are typically
context-sensitive, lossy, and very complex, so that isn't workable.)
That there has to be such an invariant follows from dgit's design
goal, which is to be a bidirectional gateway. A bidirectional gateway
is required for any kind of sane transition.
I feel I should re-explain some parts of the relationship between the
various git branches, source package imports, etc.
For an package whose maintainer git view is afflicted by
gitattributes, a tarballs-only upload with gbp and dput will apply the
gitattribute transformation. Then, a dgit user will see a .dsc
import.
Obviously it would be better for the maintainer to use dgit
push, so that the dgit user gets real history.
I think the only sane way to achieve that, if the upstream can't be
persuaded not to use this broken git feature, is for the maintainer
git tree also to not expect gitattributes to be applied. Probably the
best approach is for the maintainer to apply a patch which contains
(i) the effect of the gitattributes (ii) deletion of the
.gitattributes file, as I suggested in #1111548.
(I feel justified in saying "broken" because these .gitattributes can
cause all manner of weird behaviour. For example, I think your
version-substituting package will contain different contents in its
working tree, when you check it out, depending on what git tags happen
to exist in your local ref namespace. No reliable software can be
built on top of such shifting sands.)
In theory it might be possible to regard this is a
"maintainer-to-dgit-view" transformation. We do have such
transformations. But there are two significant objections to that:
Firstly, tree transformations are currently *only* for "3.0 (quilt)"
source packages. I think this is quite a helpful rule. "3.0 (quilt)"
is very odd, but the underlying task (maintaining a delta, long term)
is an open problem - there are multiple ways to do it, but none of
them are perfect.
Secondly, the transformations are capricious: they do different things
in different context. So what you get when you run it locally
wouldn't necessarily be the same thing as the tag2upload conversion
service sees. In your versioning example, the tag2upload service
might not have the tag that was expected to be used to substitute the
version information. This means that the meaning of a tag2upload tag
(the instruction to upload) is no longer clear simply by examining the
tag and the git objevts it references.
So I hope this explains why I think changing dgit and tag2upload to
honour gitattributes is out of the question.
That's not to say that there might not be things we can do better to
paper over these cracks and/or help the user avoid lossage.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
