Niels Thykier writes ("Bug#1079434: dgit: Can we avoid Debian specific rules
for gitattributes?"):
> When using `dgit` on a Debian package where there is a `.gitattributes`
> file, I get the warning:
>
> """
> dgit: .gitattributes not (fully) defused. Recommended: dgit setup-new-tree.
> """
Did you read the section GITATTRIBUTES in dgit(7) ?
> Concretely, I can have `git` enforce that I do not get Windows
> newlines into my scripts just because the contributor wrote the patch on
> a Windows machine in a less than ideal configured editor[2].
I can see how this is useful. I think a better approach to this kind
of thing might be to use git's hook arrangements.
> In a standard git workflow, I can edit the `.gitattributes` as needed
> and push it. From there on, branches based on that commit will now
> respect the delta. This is a nice property for me as an (upstream)
> developer.
I think maybe you have misunderstood what `dgit setup-new-tree` does.
It does not manipulate the git tree object, or your branch.
It manipulates the per-tree *configuration* (.git/info/attributes) to
arrange that the in-tree .gitattributes don't cause discrepancies
between your working tree and the git history. (Such discrepancies can
cause `dgit push-source` to fail.)
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 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.)
I agree that this whole situation is not optimal. To be honest,
I think the whole gitattributes system in git is a mistake.
(See also git subtrees which are an even more badly broken thing[1]
that dgit doesn't support.)
But the situation is not as bad as I think you imagine.
If your gitattributes don't in fact transform files, in practice,
in a way that makes your source packages different from your git tree
object, then:
* You can safely ignore the warning, since even un-defused,
the attributes won't cause discrepancies that cause dgit to fail.
* You can suppress the warning by providing a defuse line
that affects no files (see `dgit setup-gitattributes` in dgit(1))
(Possibly there could be a nicer way to do this.)
* Users who heed dgit's advice (or use `dgit clone`) will not
experience lossage either. (Assuming they don't also apply
patches with Windows line endings, or something.)
> Nevertheless, I think `dgit` should change its behavior here, since
> we are making a Debian specific git workflow and it makes Debian
> contributors that are also upstream developers a second class citizen.
I'm open to suggestions for how this could all be better. But the
situation is certainly not straightforward.
Ian.
[1] See my blog post "Never use git submodules"
https://diziet.dreamwidth.org/14666.html
--
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.
