Guillem Jover writes ("Re: sbuild vs pbuilder (and dgit)"):
> On Mon, 2016-11-28 at 17:49:53 +0000, Ian Jackson wrote:
> > There is a historical anomaly about .gitignore in source packages.[1]
...
> Got curious whether I was the guilty one, and in a way I was! :)
> I merged the patch in commit 9ddc4887306f98c4562294fb2373a2ed7d87ae67
> to the ignore list (which was not used by default back then) following
> the precedent for other *ignore files, and then that list got enabled
> by default for 3.0 formats.Thanks for engaging with my grumble in such a positive way. > I still think it makes some sense though, because this is for tarballs > that are the distribution artifacts. And if people are going to commit > the "mortal sin!" of importing those tarballs with all their autogenerated > cruft into a VCS, to be able to work there, Well, what actually happens with many packages nowadays, is that the "orig tarball" is actually generated from git by git-buildpackage. That this is a tarball is due to Debian's requirement that there be a tarball. And it is of course not unusual for a .gitignore file to be slightly out of date. So a maintainer working on such a package might well edit the .gitignore to make their life slightly more convenient. People who get the Debian source want the maintainer's fixes to .gitignore. But until dgit there was no standard way to get a git tree corresponding to the Debian source for a particular package. (The closest was git-import-dsc.) As for "autogenerated cruft": this is only a problem because our source format were capable of recording file deletion. Otherwise, we could use a crufty tarball and still have a cleanly tree for doing our own work. > they probably do not want > to ignore those same files that have been committed. This is also an > upstream common practice (not a justification for being good or not), > and for example most automake-based projects do not distribute .gitignore > files (and several of the few in codesearch.d.n that refer to them do so > for exclusion purposes). This is another good example where this .gitignore-ignorement is wrong. The right approach would be for the maintainer's git tree to not contain the autoconf output, but to contain the .gitignore. Certainly if the maintainer has a .gitignore, a Debian user who wants the package source code wants the .gitignore. But the round trip through dpkg-source throws it away. You may say that it is wrong to be transferring source code out of git, through dpkg-source, and then back into git. But given that there is no standardisation in Debian git workflows, this is inevitably sometimes necessary: The interchange format is dpkg-source, and if the user (or their tools) can't find an appropriate shortcut, the user (or their tools) have to fall back on the source package. > I acknowledge that if you are in the business of source storage > conversion and similar, not having the .gitignore files might be > annoying, and having them always makes it possible to not import > them if your workflow would suffer from that. But then maybe we should > ask ourselves why are we in that case importing from the .dsc instead > of taking the upstream VCS as the baseline to be overlaid on? Well, dgit is importing from the .dsc because the maintainer has not published, in a machine readable way, a reliable way of finding a git branch which can be used instead. dgit is currently the only way the maintainer could do that. So the answer is: dgit is importing from the .dsc because the maintainer didn't use dgit to do the upload. But of course during an upload something has to do the reverse conversion too. I have decided (and I still think I was right) that the git branches published by `dgit push' and the source packages generated by `dgit push' should have the same contents. > In any case I'll note this down as one of the grievances with format > 3.0 to take into account for future formats or revisions. Thanks! I'm still pining for `3.0 (rsync)'. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
