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
