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