Hi Daniel, Dne 24.04.2024 (sre) ob 17:33 +0200 je Daniel Gröber napisal(a): > 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 :) > Ok, so i'll prepare merge request in salsa gitlab, after pushing my change in my working branch?
> > 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? Not really, it was just an idea while reading about gbp and git-debrebase. > > > 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. I agree, i just found my fork of your git-subrepo a nice small playground. As an exercise i've converted it into a git-debrebase tree (via: man 7 git-debrebase: 'converting an existing package'). regards, Samo
