Control: affects -1 dgit-infrastructure
Stuart Prescott writes ("Re: Bug#1143449: Please defuse gitattributes in gbp
import-orig"):
> As for what is in the git repositories, I'm not sure how to answer that
> question when git-attributions like this are active; at some sort of
> philosophical level, I'm not sure that's a well posed question, given
> that these transformations are intended not accidental.
I meant the contents of the blob object referenced in the tree object
referenced by the commit. What git cat-file blob produces.
In your message you seem to take the view that what is "in git" is the
version as transformed during checkout by by the gitattributes - ie,
what you see in your working tree. But in the general case, the
transformed-by-gitattributes version of the file can depend not only
on the contents of the original blob object, but on extraneous things
like git config settings and the set of tags available in your refs
namespace (`ident` gitattribute). Also many of these transformations
are lossy (albeit only for data the transformation considers
anomalous).
In my view this means that this is not sufficiently stable to be
regarded as the meaning of a git tree object: the meaning in terms of
file contents has to be the same everywhere.
Nowadays, in Debian, whether you see the transformed file depends on
whether your git working tree has had the gitattributes "defused".
This is nowadayus done by gbp clone and perhaps other gbp operations
(as well as by dgit clone). The tag2upload builder defuses
gitattributes at the very start, because it also requires that its
output be predicteable and stable.
tl;dr: IMO .gitattributes in its current form is an ill-conceived
feature that should not have been added to git. Using it is a
mistake. (AIUI it metastasized by generalisation from a system which
would only do transformations on Windows.)
There's previous discussion in the context of dgit here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079434#20
and some debate in the context of gbp in #1092800.
This is all quite annoying. I'm quite aware that the current
behaviour of tag2upload and dgit and gbp (defusing the gitattributes)
is an unfortuante compromise, but as I say I think it's a necessary
one.
I reassigned this bug report to gbp because I think gbp import-orig
should align with gbp clone. If gbp import-orig had defused the
gitattributes then its tarball-to-git import would have contained crlf
and everything would be consistent within Debian (although
inconsistent with upstream git, but you don't seem to be using that).
> FWIW though, I do not see those as newlines in a git checkout, so what
> I'm seeing in front of me matches the tarball in the archive. I don't
> see a contradiction in that.
So, yes, you are very likely right about this. Some other users will
see something different.
> > (AFAICT actual upstream git is not being used here so isn't relevant,
> > but presuambly it has linefeeds. Four other files are affected too.)
>
> Upstream git also has CRLF for that particular file when I clone (but
> the .gitattributes ensure that).
>
> Interestingly, when downloading this individual file from both the salsa
> and github interfaces, the file I end up with is LF. I'm not sure what
> to make of that little factoid in amongst the mess of attributes, but
> thought it might be useful.
I think probably neither of these git web uis apply the gitattributes.
In the general case, how to apply the gitattributes in such a context
is not clear, since it can depend on the ref namespace, should perhaps
depend on the intended operating system (HTTP User-Agent?!), and so
on, but it is also obvious that downloading the same file from the
same commit ought not to depend on which fork of the repo we're
looking at.
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.
