On Friday, December 5, 2025 11:28:38 AM Mountain Standard Time Jai kadam wrote: > On Fri, 5 Dec, 2025, 11:48 pm Soren Stoutner, <soren@debian.org> wrote: > > 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: > > > > 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 ? Yes, you are correct. If we skip “gbp push” at step 3.e, the repository will not have the latest version of the pristine-tar branch (if used), the upstream branch, and the upstream tag. If we skip “git push” at step 3.f, the repository will not have the latest version of the debian branch. That is why both are needed. It is confusing and not necessarily obvious from the documentation. But, once you understand things, it isn’t too difficult of a workflow to follow. To round out this discussion, if you accidentally run “dch -r” before things are ready to release and then run “gbp push”, you will end up with a debian/ X.Y-Z tag in the repository that is not pointing to the code that actually was released. To fix this, delete the local debian/X.Y-Z tag, then delete the same tag on Salsa, then regenerate the tag using “gbp tag”. Then push the tag using either “gbp push” or “git push --tags” (I have done this enough times to know the process by memory). -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.