Julien Plissonneau Duquène writes ("Re: #1092800: git-buildpackage: gbp clone:
do not defuse gitattributes by default"):
> Let's start by making one thing clear: running gbp setup-gittatributes
> by default on unsuspecting users is a textbook case of regression.
I find the tone of your communicatiion hostile. Please be nice.
(I have CC'd the Community Team. CT, this disagreement seems to be in
danger of metastasising. It has appeared on -devel, in salsa tickets,
and now it's here. LMK if you need references. I'm not sure where the
right place is for the technical discussion; probably a bug against
src:dgit, not against gbp. But in any case it should be conducteed in
a collaborative way.)
Now, I am going to try to focus on the technical aspects.
> On Tue, 25 Feb 2025 10:40:27 +0000 Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
..
> > 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.)
>
> This might be dgit's core invariant but this is clearly not a git core
> invariant.
As I have explained, I think it is the only reasonable invariant
(probably, the only *possible* one).
dgit's core function - the foundation on which all the other
functionality is built - is a universal faithful bidirectional gateway
between source packages and git.
"Universal" meaning it works with every source package.[1]
"Bidirectional" meaning that it can convert source packages to git,
and convert such git trees back to source packages.
"Faithful" meaning that such round trips through git give source
package outputs which are identical to the inputs, and that building
from a git checkout and building from an unpacked source package
should give the sawme binaries.[2]
File-transforming gitattributes disrupt the mapping between git and
source packages because they are not reversible. Some source packages
would come out different when converted to git, and back again.
This would mean dgit would end up making unwanted changes to packages;
for example, someone doing an NMU with dgit (see dgit-nmu-simple(7))
might find themselves having accidentally made a bunch of line ending
transformations which would be noisy, possibly break the build, and
probably upset the maintainer.
> > but the gitattributes are typically context-sensitive, lossy, and very
> > complex
>
> The typical uses of gitattributes I'm seeing are simple and not lossy.
I was using "lossy" in the technical sensel (as in "lossy" vs
"lossless" compression), meaning not reversible. Considering, for
example, the "text" attribute, for which gitattributes(5) says:
Line endings are normalized
Normalisation is a nonreversible process.
> Some are context-sensitive, sure, that's even why they were created.
> Complex or lossy uses are unusual (my guess is less than 10% ...
dgit needs a solution that works for *all* source packages, even ones
where it is forced to *import* a tarball form into git. So a design
that works for only 90% (or even more) is not suitable.
> > When gitattributes are active, the git view will not be compatible
> > with tag2upload.
...
> But here, again, this cross-contamination is causing documented
> regressions in git-buildpackage and in salsa-ci. This "gitattributes
> defusing" technique is not safe, cannot be made safe, and should not be
> applied by default in tools that are expected to deal with regular git
> repositories.
I don't agree. My view is that *gitattributes* are unsound, and
cannot be made sound.
Defusing them is indeed incompatible with a small proportion of
eexisting git bracnhes, but typically those git branches (and/or
whatever orig tarballs we're using) can ba adapted to the new regime
without serious difficulty.
Consequently, I regard this change to git-buildpackage as a necessary
bugfix, to enable more predictable behaviour.
As I understand it, gbp has provided an override mechanism so you can
continue to work with your existing git branch. That seems like a
sensible transitional/compatibility arrangemeent.
You sound very angry. I don't understand why you are so angry given
that I believe you can continue to do things as you already have done;
all you need is to explicitly override the gbp default.
But this bug is about the default.
Ian.
[1] dgit only aims to be able to represent every source package as a
git tree, not vice versa. The cconverses - representing every git
tree as a source package - is not necessary for dgit's wider goals,
and is very difficult and probably impossible without deploying a new
source package format.
[2] Some source packages' build systmes look at the .git directory and
produce different binaries, or even fail. This is unfortunate, and
isn't something that dgit could avoid. Happily they are fairly rare
and there are workarounds; for example. building via dgit sbuild is
unaffected.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> 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.
