Resending as I realized I had accidentally dropped the debian-python list.
On Friday, December 5, 2025 11:07:44 AM Mountain Standard Time you wrote:
> On Fri, 5 Dec, 2025, 10:59 pm Soren Stoutner, <soren@debian.org> wrote:
> > On Thursday, December 4, 2025 12:45:30 PM Mountain Standard Time Andrey
> >
> > Rakhmatullin wrote:
> > > On Fri, Dec 05, 2025 at 01:12:14AM +0530, Jai kadam wrote:
> > > >> >> You can also consult its manpage to learn what does it do.
> > > >> >
> > > >> >I see, I read the man page just now after your suggestion it's not
> > > >>
> > > >> detailed.
> > > >>
> > > >> It's very detailed
> > > >
> > > >By manual you mean "man gbp" or something else?
> > >
> > > I mean gbp-push(1), you could learn that it exists from "SEE ALSO" of
> > > gbp(1).
> >
> > To add a bit more information about the behavior of "gbp push” and “git
> > push”
> > and when to use them and mix their uses:
> >
> > 1. The key to understanding this is that “gbp push” will push the
> > following
> > things:
> >
> > a. The pristine-tar branch (if in use).
> > b. The upstream branch.
> > c. Any new tags on the upstream branch.
> > d. The debian branch, but only if the changelog does not target
> > UNRELEASED.
> > e. Check for a new tag in the debian branch for the latest changelog
> > entry
> > and push it, but only if the changelog does not target UNRELEASED.
> >
> > 2. What we want to avoid is pushing a debian/X.Y-Z tag on the debian
> > branch
> > before X.Y-Z has actually been accepted into Debian.
> >
> > 3. The following workflow accomplishes this:
> >
> > a. gbp import-orig --uscan (this updates pristine-tar if used, the
> > upstream
> > branch, the debian branch, and creates a new upstream tag).
> > b. dch (adjust the changelog version number accordingly, but leave the
> > target as UNRELEASED).
> > c. gbp buildpackage (make sure the package builds).
> > d. <Fix any problems>.
> > e. gbp push (this pushes pristine-tar if in use, the upstream branch, and
> > the
> > new upstream branch tag, but not the debian branch because the changelog
> > targets UNRELEASED).
> > f. git push (this pushes the debian branch).
>
> Noted! :)
>
> > 4. When ready to release:
> >
> > a. dch -r (this changes the target from UNRELEASED to unstable, edit to
> > experimental if desired).
>
> This is same as dch --release rigth ? Si it also adds the commit messages
Yes, “dch -r” and “dch --release” are the same.
> b. gbp buildpackage (build the package with the final changelog).
>
> > c. Upload the package.
> > d. gbp tag (this creates the debian/X.Y-Z tag, typically one only does
> > this
> > after the package has been accepted into Debian).
> > e. gbp push (this pushes the debian/X.Y-Z tag).
>
> That is use gbp push only once at the very end , right?
No, you also use “gbp push” in step 3.e above. Otherwise, you need to use
multiple git commands to do the same things, which would be to push the
pristine-tar branch (if in use), the upstream branch, and the upstream tag.
If these things are not done at this step, other people who clone the
repository cannot build the changes you have just made. When reviewing
packages that other people have submitted to mentors I do the following.
1. gbp clone (if I haven’t already cloned the repository).
2. gbp pull (this pulls all three branches and the tags, so that I can review
the most recent changes).
3. gbp buildpackage.
If you don’t get step 3.e and 3.f right, "gbp buildpacakge" will fail for me.
Oh i see cause debian-branch will have the previous version of code cause gbp never uploads it while in unreleased state and we only do dch -r when we get a green flag from a mentor or maintianer of the package which then sets it to unstable and then when we run gbp tag and gbp push all work is done.
Is my understanding rigth ?