Re: Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)
On Sun, 11 Aug 2019 15:03:51 +0200, Daniel Leidert wrote: >Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons: >> Upstreams are starting to use git lfs in their git repos. In some cases >> the git-lfs references files are retained in the source tarball, not >> replacing the reference with the actual files. This happens for >> instance with github repos (I gather it happens because the tarball is >> generated with 'git archive' [1]). An example is the mesh files [2] in >> pygalmesh 0.4.0 [3]. > >What I really don't understand is, why we duplicate upstream files (now even >really large files) on salsa.d.o. The debian/-only approach (or "overlay" >layout in git-buildpackage) works fine. Salsa CI also works just fine. When I started with mantaining my packages in git, that layout way not yet available. Actually, this was my major beef against git since I had been using this approach happily with svn und svn-buildpackage for years. I haven't heard that a debian/ only repository layout is possible with git-buildpackage before today. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)
On Sun, 11 Aug 2019 at 15:03:51 +0200, Daniel Leidert wrote: > What I really don't understand is, why we duplicate upstream files (now even > really large files) on salsa.d.o. I can't tell you every maintainer's reasons to do this, but here's why *I* prefer having upstream source code in our packaging git repository: * When I'm investigating a bug, I don't need a separate repository and a separate checkout to look back through the history of the code that is under suspicion and find out why it is the way it is. * When I'm rebasing our patch series on updated upstream source code, I don't need a separate repository and a separate checkout to do so. (I use gbp-pq for this; other workflows are available.) * When I'm trying to fix a bug, I can switch to the patches-applied view (in my case this means gbp pq import) and try repeated rebuilds until it works. I don't need to have a separate repository and a separate checkout of the upstream source code, apply the Debian patch series, work out how to build that in a way that is compatible with the expectations of the Debian package, iterate on the new patch, and finally export it (git format-patch) in a form that I can add to the Debian packaging. * If upstream's VCS repository disappears or goes offline, either temporarily or forever, we still have the history up to this point (and if necessary we can fork). When GNOME's Debian packaging was still in svn, all of those except the last were practical problems. I find it much easier to work with GNOME packaging now that we're using git with full upstream source. The one family of packages for which I still don't use a full-upstream-source git repository is openarena-data, because game data/assets have limited history (they get added and occasionally deleted, but rarely modified) and limited scope for patching, and are inconveniently large. smcv
Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)
Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons: > Upstreams are starting to use git lfs in their git repos. In some cases > the git-lfs references files are retained in the source tarball, not > replacing the reference with the actual files. This happens for > instance with github repos (I gather it happens because the tarball is > generated with 'git archive' [1]). An example is the mesh files [2] in > pygalmesh 0.4.0 [3]. What I really don't understand is, why we duplicate upstream files (now even really large files) on salsa.d.o. The debian/-only approach (or "overlay" layout in git-buildpackage) works fine. Salsa CI also works just fine. I cannot find anyhting useful in storing the upstream files in our Git. Also all other distributions I know, which store their packaging files in a VCS, only store *their* files, not the upstream sources. Do we really have to waste our resources? Regards, Daniel signature.asc Description: This is a digitally signed message part
