Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.project > #10824

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

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

Show all headers | View raw


* 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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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