Dear Maintainers,

Could you please change `gbp clone` defaults to NOT run `gbp setup-
gitattributes` by default?

This is related to the issues reported in [1].

Blindly disabling .gitattributes is likely to break things that would otherwise
be perfectly working such as the cases reported above. It might cause wrong
encodings or line endings to end up in input data for test cases (and make them
fail), or in scripts intended for other operating systems. It should really be
reserved to the rare cases where upstream .gitattributes configuration make
packaging work difficult or impossible, and even then it has caveats.

A link to a MR to implement this change will follow.

Best Regards,


[1]: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/409

A merge request is available here:

https://salsa.debian.org/agx/git-buildpackage/-/merge_requests/38

Best Regards,

Julien Plissonneau Duquène writes:

I strongly disagree with this suggestion.

Transforming gitattributes breach many obvious invariants, and gbp
should disable them by default for the same reasons as dgit does:
https://manpages.debian.org/bookworm/dgit/dgit.7.en.html#GITATTRIBUTES

When gitattributes are active, the git view will not be compatible
with tag2upload.

Ian.

It causes documented and reported problems where there were none.

It can and will cause problems even when following the documentation and
using the recommended tools to clone the repository.

And it can't even be fixed because this whole "gitattributes defusing"
implementation is fundamentally flawed and built on wrong assumptions.

For all these reasons it's unsuitable as a default.

The invariants you are referring to here were invented by you and are
explicitly conflicting with the invariants intended by the designers of
git.

You, from [1]:

This might be dgit's core invariant but this is clearly not a git core
invariant.

Linus Torvalds, from [2]:

And this is exactly what your own pick of invariant does. If that quote
above (and the whole discussion around it) isn't clear enough about how
the developers of git decided it's perfectly fine to have working tree
content that is different from checked-in content and have
transformations applied both ways, I don't know what else would.

Focusing on [1] again:

The typical uses of gitattributes I'm seeing are simple and not lossy.
Some are context-sensitive, sure, that's even why they were created.
Complex or lossy uses are unusual (my guess is less than 10% of
gitattributes usages, which are themselves a small fraction of git
usages) and even then I'm not sure that many of these unusual cases are
actually causing issues with packaging — excepted with dgit. I've asked
for examples of problems multiple times on multiple threads and so far
absolutely no one came up with actual examples. But let me try once
again FTR: could you please provide a few examples of packages+versions
where upstream gitattributes settings are/were breaking Debian package
builds, besides dgit breakage?

Your own choice is actually even less workable outside of a very narrow
set of workflows but you are failing to realize that. Ignoring the
problems won't make them go away. See #1099741 [3] for yet another
example of how it still fails in even the simplest cases and confuses
users that AFAICT did nothing wrong.

That's not a reason to make the situation worse for everybody
encountering these while "spinning" the issue in manpages. I'm not a big
fan of gitattributes either, but they made sense in e-mail based
workflows (as there is no reliable way to ensure line endings will be
preserved in text/* MIME media types across the diversity of clients,
tools, servers, systems and user configurations) and they still make
sense today especially in large cross-platform projects where specific
line endings are required in some input files.

I do not agree with the way this short section of man page is framing
the issue. Should I file a bug report and a merge request rewriting it
to document that in detail as well?

I'm not against experimentations and innovations and if you want your
dgit repositories to diverge from regular git repositories that's your
right, as long as this divergence is properly documented (that is, your
users are fully aware of what they're getting into and why), confined to
your experimentations and tools, and not forced at any cost on the whole
toolchain.

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.

Best regards,


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079434#10
[2]:
https://lore.kernel.org/git/Pine.LNX.4.64.0702130845330.8424@woody.linux-foundation.org/
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099741

Julien Plissonneau Duquène writes ("Re: #1092800: git-buildpackage: gbp clone: do not defuse gitattributes by default"):

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.
..

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.

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.

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.
...

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.

Le 2025-03-24 14:09, Ian Jackson a écrit :
systematically ignore the arguments and the evidence presented by the
other party. Look at what just happened here: I claim that the issue at
stake is definitely a case of regression, with arguments supporting that
claim, and this bug report links to multiple evidence backing that
claim.

I take extra steps to make sure you cannot ignore that claim: I start
the message with it, conclude with it, and use a direct, straight to the
point, unambiguous formulation that you perceived as "hostile".

So I got your attention, but your only comment about that specific claim
(which is nothing less than the core of the issue) is about the tone of
the communication, and that's it. You didn't even agree or disagree with
that claim, there isn't even a hint that you considered it, you just
ignored it and dismissed it completely. And in your technical
explanation that follows you adress absolutely none of the problems that
I've pointed out in your approach.

I'm sorry, but I do not consider that respectful either, and certainly
not a discussion "conducted in a collaborative way", especially as this
is a recurring pattern in these discussions. It's possible that you do
not even realize that you're doing this; please pay attention.

Thank you. This is appropriate here and I will keep the Cc; I was
considering contacting them myself as I believe there is a very
unhealthy dynamic going on here, with a few developers pushing their
views and projects at any cost on critical toolchain components without
due discussion and consideration for the issues that they cause.

For now I'm asking for a change in gbp, not dgit, so here is definitely
the appropriate place to discuss this. Otherwise there is a thread [1]
waiting for you on debian-devel for a discussion across several tools.

So we disagree. I think your choice of invariant is definitely not a
reasonable one as it breaks compatibility with upstream repositories and
common tools and it is never going to cover all possible use cases
anyway. The steady flow of build issues it causes is the proof that it
doesn't work as a universal or even just as a reliable approach.

I also believe that it should be possible to get dgit to work with the
other (and the only correct, from a git perspective) invariant, and that
achieving that would lead to fewer issues overall than the current
approach playing dirty tricks with attributes. This is indeed going to
require some hard work and would be worth a discussion maybe on a dgit
bug report if you were open to reconsidering this position of yours. So
far I'm convinced that you are not, so I won't bother opening it unless
I can have any hope that an actual discussion may happen, and not just
one-way communication repeating the same things over and over.

In the meantime, I fail to see why breaking gbp and salsa the same way
as dgit is an absolute necessity, so I'm asking their maintainers to
revert this default which has been demonstrated to be a regression.

It doesn't anyway. For example there are source packages that ship empty
directories and expect them for their build, and AFAICT dgit can't
satisfyingly deal with these.
where this would happen?

One thing I can tell you as a maintainer is that I would definitely be
upset if the git repositories I work on were to be converted to dgit
repositories. I'm now considering implementing defences in build scripts
to make sure this can't happen without having to read a few things
first.

These transformations are reversible in projects that are correctly
setup upstream. Maybe you have a few actual examples where they are not,
as previously requested?

But I will happily reuse the same argument for gbp: a default that
doesn't work for *all* expected use cases is not suitable (excluding
dgit+gitattributes use cases, as dgit in its current form is to be
considered broken by design in these cases). This is why I'm asking to
revert this default.

And my view is that this gitattributes defusing trick is unsound and
cannot be made sound. So I guess we agree to disagree there.

No they can't, without breaking out-of-the-box compatibility with other
git tools and repositories. Once again you are dismissing issues here.

This is not a bugfix as it doesn't fix anything, it just breaks things
further. This is a regression, by the very definition of "regression".

Yes now I'm aware of the issue, after having spent too much time on it
already, and occasionally still stumbling on it. Others are going to
keep stumbling on it as well, and lose time for no good reason as I am
pretty certain that the actual and proven drawbacks of having attributes
defusing implemented as a default far outweigh the hypothetical and
unproven benefits.

Have you considered that, maybe, attempting to discuss these things with
you is a frustrating experience?

Sure, but I also need to tell others to override the unsafe gbp default
for working with some repositories, and I expect that once in a while I
will have to explain things to people that didn't read instructions, or
fix said instructions as new paths to breakage are appearing. This is
not exactly the most pleasant perspective.

Yes it is. That should not be such a big deal to let this go and revert
this unsafe default, right?

Best regards,


[1]: https://lists.debian.org/debian-devel/2025/02/msg00285.html

Julien,

You have now been asked several times in different places to take a more
constructive tone.  Around here, if someone asks someone to be nice, we
don't respond by just counter-accusing.  Especially not when the other
person has just taken the time to respond in detail to your specific
concerns.  That is not how we get along with each other in Debian.

Assume good faith, please.  You are currently failing to do that.

Le 2025-03-25 02:35, Sean Whitton a écrit :

Believe it or not, I'm doing my best here.

Explain me then how one is supposed to call out the fairly unhealthy
kind of passive aggressivity I'm facing in these exchanges?

Did you actually read my last message beyond the first sentence? The
first four paragraphs are demonstrating how the response avoided to
address (or even consider) my specific concerns.

Again, I'm doing my best. It's just not that easy to keep assuming good
faith given the behaviour I'm facing from you and Ian.

Best regards,

Hi,

So I've followed your link chain from [1] and randomly picked kotlin and
what I see there is that `gbp clone` leaves a checkout with changes
since the .git/info/attributes is added too late (when files are already
checked out). So I think what we should do in gbp is either make sure
attribtes apply during clone or ensure that the checkout is adjusted to
the changed attributes after clone (e.g. via the equivalent of `git
checkout -f`). I think that's indeed a bug in gbp-clone that should be
fixed. I've opened

https://salsa.debian.org/agx/git-buildpackage/-/merge_requests/49

for that.
Cheers,
 -- Guido

Hi Guido,

Thank you for looking into this issue. Unfortunately you closed your MR
before I got a chance to comment, and AIUI the proposed fix is just
going to replace this issue by another as now the re-checked out content
won't match what's in the source tarball.

As a reminder I've implemented a test case in the other merge request as
commit 1f0ad64e [1], could you please pick this commit and use it to
test your alternative attempts to resolve the issue to make sure they
don't introduce other issues?

Best regards,


[1]:
https://salsa.debian.org/agx/git-buildpackage/-/commit/1f0ad64e3f6fdaf24aa72d0da46934e0003dc6aa?merge_request_iid=38

BTW more background to this design decision in the context of dgit
can be found in this bug against src:dgit

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079434

Hi,

The MR was merely to fix the current behavior of actually applying the
result of `.git/info/attributes` to the just created repo. You e.g.
couldn't `gbp buildpackage` with such a clone (as it has uncommitted
changes) and a `git checkout -f` would get you into another state which
you can't get out of afterwards which I don't think are the users
expectations. So consider that a fix of the `--defuse-gitattributes=on`
mode not an "attempt" to do something else.

This is orthogonal to whether attributes should be defused by default or
not.

I've taken a chunk from your MR to add a test for the defusing step.

Cheers,
 -- Guido

Le 2025-03-26 11:08, Guido Günther a écrit :
incompatible with git LFS which is used by some upstream projects.

Cheers,