Hi Daniel, Dne 12.04.2024 (pet) ob 16:02 +0200 je Daniel Gröber napisal(a): > > +git-subrepo (0.4.6-1) unstable; urgency=medium > + > + [ Daniel Gröber ] > + * Fix Vcs URLs, s/guest-dxld/dxld-guest/ > + * Update changelog for 0.4.3-2 release > > Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does > usually filter those out. > > + * Add salsa-ci config > + * Revert "Update changelog for 0.4.3-2 release" > > I would collapse such VCS artifacts too since the changelog is from the > perspective of "what changed since the last version" in the end, not a blow > by blow of the git changes we used to get there. It's a judgement call tho. > > + > + [ Samo Pogačnik ] > + * Updated debian/control info > > Needs to be a lot more specifict than that. In d/changelog you're talking > to two main groups of readers: other Debian contibutors (i.e. me) and > actual end users. Does this tell me what I need to know to figure out why > you made that change? Not really. > > Looking at the diff it should have even been two commits "d/control: Point > Vcs at samo" and "d/control: Make myself Maintainer". >
Thanks for the review. I followed your suggestions above and recommited d/control and d/changelog. > As for the Vcs change: I'd prefer if we put the git repo in the debian/* > namespace on Salsa. > Here i am not sure who can / how to do this? > > I also made another git-subrepo_rebase project ( > > https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with > > rebasing of debian branch onto each renewed upstream. I assume rebasing > > workflow > > shoud somehow avoid commiting patch series into main-working branch. I > > understood git-debrebase figured that out, but ... (see below) > > I have a hard time figuring out what is going on in your repos. Damn I > already hate gbp from a review standpoint. > > I'm not sure you've internalized this, with gbp you really don't want to do > any manual git-pull/git-merge calls. Let it do it throught it's > gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of > me when I try to review the package. > I feel i owe you more explanation of what i am trying to achieve here (now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The idea was to reverse the gbp's view on its branches, where the debian/sid is the continuous branch and the patch-queue branches are the intermediate and temporary ones. In this experiment i am trying to have the patch-queue branch the main continuous branch, brought (by any git means) to the state, where one could do 'gbp pq export' to a fresh debian/sid branch rooted before any upstream commits grouped at the end of the patch-queue branch. So, when a new upstream version is to be integrated (after pulling the upstream repo): --- 1. a copy of current patch-queue/debian/sid branch is to be made for future reference and current debian/sid branch renamed (i.e. *debian/upstream_version). 2. rebasing main patch-queue branch onto upstream at its new release 3. squashing existing d/* commits of previous releases into a single commit 4. do any necessary work on d/* and upstream code to make things work in new version 5. rebase/reorder commits after the squashed commit on patch-queue branch to put any d/* commits in front of any upstream commits 6. create a new debian/sid branch from the latest d/* commit 7. on patch-queue branch run 'gbp pq export' to generate final changes (patches) on new debian/sid --- For each new debian release (same upstream), a similar procedure is needed: --- 1. a copy of current patch-queue/debian/sid branch is to be made for future reference and current debian/sid branch renamed (i.e. *debian/debian_version). 2. do any necessary work on d/* and upstream code to make things work in new debian release 3. rebase/reorder new commits on the patch-queue branch to put any d/* commits in front of any upstream commits 4. create a new debian/sid branch from the latest d/* commit 5. on patch-queue branch run 'gbp pq export' to generate final changes on new debian/sid --- The main problem i face is: How to run test builds directly from patch queue branch to get equivalent 'snapshot' results as from the final debian/sid branch? > > I watched video about git-debrebase and it seemed reasonable to me at first, > > however they lost me when dgit and pushing to dgit repo got into play. > > The history structure does get a bit confusing yeah. My main takeway: > "patches applied" workflows exist *mind blown*. I hadn't seen that yet, > exactly what I've been looking for since gbp-pq sucks and quilt is no > better. I just want to use striaght up git damn it and that's what > debrebase and dgit seems to let you do :) > I somehow managed to avoid quilt until now so i can not really comment it, but i agree that having a patched git branch is light years better than having a series of patches acompanying the original code. > > I'm actually tending to just jumping onto dgit. Should actually make things > easier for you once I figure out how it works. There's even nice docs for > the sponsorship workflow > https://manpages.debian.org/testing/dgit/dgit-sponsorship.7.en.html unlike > with gbp where upload sponsorship seems to just not have been considered in > it's design if my DM experience with it is any indication :D > > Opinions? I feel/hope debrebase is doing something similar as my little experiment but with all the debian specific bells and whistles, i am currently not even aware of. I would say that, if dgit/debrebase provides a workflow without messing with patch-sets (and tarballs), then this is the tool... regards, Samo
