Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.project > #10824
| From | Florian Weimer <fw@deneb.enyo.de> |
|---|---|
| Newsgroups | linux.debian.project |
| Subject | Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa |
| Date | 2019-07-24 22:20 +0200 |
| Message-ID | <ynvTX-6Fj-1@gated-at.bofh.it> (permalink) |
| References | <yn7eW-7NO-19@gated-at.bofh.it> <ynb8S-21u-5@gated-at.bofh.it> <ynt5L-4Pg-11@gated-at.bofh.it> <ynt5L-4Pg-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
* Bastian Blank: > On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote: >> On 7/23/19 11:59 PM, Adam Borowski wrote: >> > Big fat enormous NO! gbp is a workaround for the biggest evil in our >> > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the >> > impression that if we dropped the VCS-in-VCS approach, there'd be no need >> > for most of that complexity. >> How do you track what you've applied in Debian, and the status of your >> patch upstream? With DEP3 patch headers in d/patches, we track this easily. > > git cherry-pick to get new changes. git diff to get all changes, git log > to list changes. You just need to know the branch point. I expect you'd need some more tool support to find backports that did not properly converge after an upstream merge (that is, importing a new .orig.tar.gz in the current model), so that you can be aware and remove the lingering difference. For partially diverging trees, “git diff” might be a bit too much. However, I do think that such tooling will be far simpler and more deterministic than any two-way Git importer (having written one of those for RPM spec files, complete with LCS-based editing of Patch:/%patch directives). But isn't a GR a bit premature? I would have expected something to build directly from salsa.debian.org first—like how Fedora builds from Git repositories on src.fedoraproject.org. I'd hope for something without VCS-in-VCS, but even if you prefer that, but build-from-salsa applies to any approach which mandates a centralized Git (in addition to the already-centralized archive). (I really hate VCS-in-VCS, although I know it primarily from a non-Debian context these days.)
Back to linux.debian.project | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Adam Borowski <kilobyte@angband.pl> - 2019-07-24 00:10 +0200
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Holger Levsen <holger@layer-acht.org> - 2019-07-24 00:30 +0200
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Bastian Blank <waldi@debian.org> - 2019-07-24 19:20 +0200
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Florian Weimer <fw@deneb.enyo.de> - 2019-07-24 22:20 +0200
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa Bastian Blank <waldi@debian.org> - 2019-07-24 19:30 +0200
csiph-web