Let's start by making one thing clear: running gbp setup-gittatributes
by default on unsuspecting users is a textbook case of regression.
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.
On Tue, 25 Feb 2025 10:40:27 +0000 Ian Jackson
<[email protected]> wrote:
Transforming gitattributes breach many obvious invariants
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 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.
Linus Torvalds, from [2]:
No no no.
It's going to be _horrible_ if people start interesting projects in
Windows, and there are files in a git repository that are encoded with
CRLF.
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:
but the gitattributes are typically context-sensitive, lossy, and very
complex
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?
so that isn't workable.
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.
I agree that this whole situation is not optimal. To be honest,
I think the whole gitattributes system in git is a mistake.
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.
On Tue, 25 Feb 2025 10:40:27 +0000 Ian Jackson
<[email protected]> wrote:
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
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?
When gitattributes are active, the git view will not be compatible
with tag2upload.
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/[email protected]/
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099741
--
Julien Plissonneau Duquène
