On Thu, 13 Feb 2025 13:15:01 +0100 Liliana Marie Prikler <liliana.prik...@gmail.com> wrote:
> Am Donnerstag, dem 13.02.2025 um 10:30 +0000 schrieb Attila Lendvai: > > > Here's my perspective: it will cost us basically nothing to rename > > > the master branch, > > > > i suspect you'd be surprised how many places will need to be touched > > until the whole infra is back on track after such a rename... > > > > e.g. consider just the "bootstrapping" of this rename: > > > > if you simply rename the branch, then people won't be able to guix > > pull after the rename. > > > > if you keep two branches, then for how long until no users are left > > who will attempt to guix pull using an unprepared guix binary? > > > > or should we add code to guix preemptively that can deal with both > > the pre and post rename environment? then have a grace period before > > the rename? for how long? > Consider these steps: > > 1. Create 'main', following 'master'. > 2. Push a commit that makes 'main' the branch of > %default-guix-channel. > 3. Push that commit to both 'master' and 'main'. > 4. Lock master on said commit. This doesn't take care of existing repositories, and it is possible to handle that as well but the way I know does require practical control over the infrastructure (there may be better ways though that works without ssh access): $ git checkout origin/master -b temporary $ git push origin HEAD:main $ ssh root@server $ cd /path/to/repository.git $ git symbolic-ref HEAD refs/heads/main # Change the main branch $ git symbolic-ref refs/heads/master refs/heads/main # Make master point to main I did it on many Replicant repositories for instance, and it's 100% transparent to the users. With that, new clone of the repositories use main by default. Denis.
pgpjLYUq4tLOZ.pgp
Description: OpenPGP digital signature
