On Thu, 28 Aug 2025 15:04:42 -0700, Otto Kekäläinen wrote:
>Also dep12-migrate performs the actual migration, while >dep-14-convert-git-branch-names.sh only suggests what should be done.Running dep-14-convert-git-branch-names will print a list of commands to run, which you easily can just copy-paste to run.
4000 times? Manually? Seriously?
The script also has option `--apply` to run those commands automatically, but it hasn't been enabled yet as we don't have enough users and confidence that all corner cases are covered.
Ack.
What's still missing is a solution for locally checked out clones on Other People's Laptops, as git will blow up if the remote changes from "upstream" to "upstream/latest" and they git-pull/gbp-pull/mr-up …So what exactly happens if a collaborator already has a git clone of a repository and the maintainer renames upstream -> upstream/latest? When the collaborator runs either `gbp pull` or `git pull` it will print out something like this: ± gbp pull --track-missing xxx gbp:info: Fetching from 'xxx' gbp:error: Error running git branch: fatal: cannot lock ref 'refs/heads/upstream/latest': 'refs/heads/upstream' exists; cannot create 'refs/heads/upstream/latest'
Ack.
To fix this, just run: ± git branch -m upstream upstream/latest
4000 times? Manually? Seriously?
Seems that latest git 2.51+ (now in unstable) detects this situation and does the reference rename automatically on the fly,
A change in a remote from "upstream" to "upstream/latest" doesn't explode anymore? If yes, that would indeed to totally great.
but for Bookworm and Trixie collaborators unfortunately need to run `git branch -m upstream upstream/latest` once. If you mention this in the git commit message that updated gbp.conf, they might see it.
4000 times? Manually? Seriously?
The biggest contribution would of couse be if someone could help Guido and take on Bug#829444 so that git-buildpackage by default on *new* repositories would use DEP-14. If we don't have that, these "migrations" will keep on going forever.
I think that's not the problem for packaging teams, as their tooling (at least for pkg-perl but I guess for others as well) already do this since quite some time.
The challenge for large packaging teams is (always, this is not the first case) how to change thousands of existing repos both remote and locally.
Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe`-
signature.asc
Description: Digital Signature
