From: gregoa@debian.org 
  
 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 
     `- 
  
 -----BEGIN PGP SIGNATURE----- 
  
 iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmiw1j9fFIAAAAAALgAo 
 aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx 
 RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ 
 qgZTBA/+P2f6BrE+JwMZX5VWMlf8vEcdlWxfbDWNaRy5DJm1P3PK4ah9AeAB/nap 
 74vw/2tNqsL6RaPnQLScNEsKuH+/NCg1KKbYzgXOgdJV5M7ryUeehWqUmWoKpyIL 
 5jePzD0VzurL6E3VwRl1WXUZywtB/2UfL+fLrKg3sQWiZ2I9jR83TzPjBRTPPd2C 
 OVnnySV//szh0DF68lXWGruQjxRIQu2GkYzVkyEZaLuuGJDl2oDt0ZVms/dYJIuw 
 VA6Q8+HQhHxmRNhEDXJtp5v+u2JKRlWOcrB1UwwrBv6NTWRW3a115FnJVe0SfIqn 
 YxJkyW9qLHcEkIvHHS6+XnvOQgtSX15mrFOsh62QO4A+K3F2zhWbW7qRJzfTGF6R 
 lAFgTcvdvpU0fAUxLHuSa/+lbq1O1L0Wqny1HgNwtQqUR6pi+ekxohCOsi/apcel 
 yYlcpVdHk/nDxgpfW73rLlIMLy+qy5seHPfEJRAvzeujC4zv/7JGN2KSDe2GZEhv 
 lwJj9fgK1zJN6ldxJ+/JG7+Bh1/DdKOIQ9pbOgpEdAYow5RT6ym7H69uybw+c/wH 
 /CD5CNwC9GS9GZ9vQPTbBCFgneYnbupCVorXSK7bK7iua8w2DPcAm9Pn2NNIxbdf 
 5MIF1ONvClHdyRSbCFSH02rUys//KWwFru9d+Ro2esz9q56ee9Q= 
 =Waj1 
 -----END PGP SIGNATURE----- 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)