On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote: > Ok, so i'll prepare merge request in salsa gitlab, after pushing my > change in my working branch?
So creating a MR is fine but it's not the whole story with gbp. With gbp you're always dealing with both a debian and an upstream branch so the MR model doesn't fit since it just deals with the one branch you point it at. That doesn't really hurt as long as you remember to push your upstream branch also since I won't be pressing that merge button on the web ui anyway. Technically I can still just assume your upstream branch points to the upstream/* tag you push -- assuming you don't forget to push the upstream tag. Seriously this workflow has so many trap doors for DMs it's insane :) Anyway. What I want to see is a nice linear series of sensible commits with your packaging changes and one merge to bring in the new upstream [history] on the debian branch, the conventional upstream/* tag and the corresponding upstream branch which should be fast-forward from the previous upstream history. [history]: That's the one default gbp workflow tweak I insist on when it's possible i.e. when the need for dealing with tarballs doesn't get in the way. I want git-blame to work in packaging repos. It's increadibly valuable for debugging but squashing the upstream changes as import-orig defaults to looses most of that context. So you should be doing something like this: $ git remote add upstream https://github.com/ingydotnet/git-subrepo.git $ git fetch upstream $ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch # changes and create the merge $ gbp dch <make sure the changelog entries makes sense> $ gbp buildpackage [...sbuild runes...] <test> $ git push --tags salsa debian/sid upstream There's also `gbp push` to make the git-push easier but it only works after doing a `gbp tag` to create the debian/* tag. This is however inappropriate for you as DM to do as the convention is to have the debian tag correspond to what I upload not what you propose to me :) On my side I'll do: $ gbp pull samo <review> $ gbp buildpackage [...sbuild runes...] <test> $ gbp tag # creates the debian/* tag $ debrelease # upload to ftp-master $ gbp push salsa Hope that gives you something more actionable than my previous mails. > > Have you found any docs for this workflow? > Not really, it was just an idea while reading about gbp and git-debrebase. Right, that's what I figured but I wasn't sure :) > > 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'). Playing with this stuff sure is important to figure out whats going on ;) --Daniel PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do like to keep Debian work public and that includes teaching new contributors, do you mind if I copy our conversation back to the BTS?
signature.asc
Description: PGP signature