Hi Samo, On Mon, Apr 08, 2024 at 09:01:24PM +0200, Samo Pogačnik wrote: > > Anyway gbp has reasonably good documentation, maybe you haven't seen it yet: > > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html > > (note the navigation buttons in the top right) > > Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo > according to gbp manual and now i am not sure if generated changelog is ok.
You can just edit the changelog `gbp dch` generates. I do find it fucks up most of the time the way I use it and just edit it. I am starting to think gbp is more trouble that it's worth now that I'm starting to look at some of the other workflows... +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". As for the Vcs change: I'd prefer if we put the git repo in the debian/* namespace on Salsa. + + -- Samo Pogačnik <samo_pogac...@t-2.net> Sun, 07 Apr 2024 19:31:14 +0000 > 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 wish we could use a rebase workflow with gbp but I haven't found a way to > > do it yet. At least not with gbp import-ref as-is. We could work on a patch > > for it I suppose ;) > > > I think i am a bit too green for that Maybe, maybe not. Only one way to find out. > 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'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? --Daniel
signature.asc
Description: PGP signature
