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. -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.