[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

> 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.)

Reply to: