Hello, On Tue 17 Jun 2025 at 12:41pm +01, Ian Jackson wrote:
> While uploading src:dgit to expeerimental, I discovered that my git > remote was misconfigured. So it made the tag, but then failed to > push. This isn't a very nice failure mode, particularly because > fixing the config and retrying doesn't work because the tag has > already been made. > > I suggest: > > * After doing all the local checks, but before making the tag, run > git fetch on the selected remote. (Not in --tag-only and > --print-tag-text modes.) We should probably do a ref-limited fetch > covering the tag we are proposing to make, and > > * Check that the local branch is ff from the remote. (If it isn't > then someone has pushed to salsa in the mesntime. Probably, the > user wants to know about this.) > > * If the remote branch is ff from the local one, do not attempt to > push it. This can happen if the user overrode the previous check, > an is deliberately tagging an older commit. > > It also happens if the remote and local branches are the same. Not > pushing the branch in this case is good because it means that if > the git-debpush user is racing with something on salsa, the push > doesn't fail after making the tag. > > This might also help with a forge that prevents "git push" and only > allows explicit MR merge operatiuons. Gitlab has that option, but > empirically it doesn't object if the push you're making won't > actually update the remote ref. This sounds good. > * Provide options which can be used to retry a push, including > a way to push only the tag. How about --retry-push > and --no-branch (= `--branch=HEAD~0`). I'd suggest something different: if the tag already exists, offer a y/n prompt to retry the push. I think it should always attempt to push the branch and the tag. If the user wants to get into pushing individual items, they should just use 'git push' themselves. This avoids adding any new options. > For testing, we may want to invent a new test case that just tests > git-debpush corner cases but doesn't invoke the whole t2u machinery to > process the actual tag. That would also help us in the future when > we'll want to update the server-side machinery to new dependencies but > still be able to test git-debpush on old releases. Yes, I've been thinking similarly. -- Sean Whitton
signature.asc
Description: PGP signature
