Hi Samo, On Mon, Apr 15, 2024 at 09:13:03PM +0200, Samo Pogačnik wrote: > 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'll push the repo there and give you access, you just have to adjust the Vcs-* fields and get those changes to me in a way that I actually want to accept them ;P FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but I'm still trying to hone your git collab maintanance skillz :) > 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. I have to admit I've never really considered this to be a possible workflow. Honestly I don't think it's a good idea to hold a loaded gun (gbp) the wrong way round ;) Have you found any docs for this workflow? > 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. git-subrepo is a relatively simple upstream so I would really not deviate from established and documented workflows for it. I get you probably want to explore the possible git workflows in Debian and admittedly my idea to use git-debrebase is probably also severe overkill (and I'm also guilty of just wanting to play with it too ;). I've thought about it some more and perhaps we should for now use something simpler (plain gbp) until you get the hang of it and/or the (unapplied) patches actually get in the way. > So, when a new upstream version is to be integrated (after pulling the > upstream repo): tl;dr honestly. Look, we already have too many possible workflows for git maint. in Debian adding a new one that doesn't have wide usage yet isn't going to help unless it brings something new to the table. So how does this compare to the other 50 workflows? :^) > 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... There's no escaping tarballs in Debian :3 Except maybe with dgit but even then you need to think about calling origtargz... *chanting* In the tarball, part of the tarball, in the tarball, part of the tarball ...[ad nauseam] https://youtu.be/SxGjdx1NXfg?feature=shared&t=49 and also: https://www.youtube.com/watch?v=EM9kl6jY09A --Daniel
signature.asc
Description: PGP signature
