# Git default branch master->main

XMLWordPrintable

#### Details

• Type: RFC
• Status: Implemented
• Resolution: Done
• Component/s:
• Labels:
None

#### Description

A number of developers have asked that we follow the new git and Github conventions and switch our default branch from master to main.

Background:

https://sfconservancy.org/news/2020/jun/23/gitbranchname/

https://github.com/github/renaming

and we now have new repos created with the new default name, thus now introducing a level of inconsistency that will only get worse.

RFC to:

1. Change the dev guide https://developer.lsst.io/work/flow.html#the-master-branch
2. Propose we ask TCAMs to organize a day (it's the kind of thing we used to do at team all-hands) to switch existing repos and other documentation references.

(Indigenous People day is Oct 12, just saying and many (most?) of us don't have employers who observe it so there's an idea)

#### Activity

Hide
Kian-Tat Lim added a comment -

Unfortunately, git symbolic-ref main refs/heads/main may allow master to stay pointing to where main does, but my experiments seem to show that it is not the equivalent of a real branch, and commands do not work identically: e.g. git checkout master gives "detached HEAD" state, and I suspect merges will also be problematic. Also, I believe that the symbolic ref is only local to a clone; it does not seem possible to make it mandatory for all new clones.

If you are concerned about muscle memory typing the wrong branch name, you might try to use git checkout - or git switch - instead. It's shorter, and quite often what you want.

Show
Kian-Tat Lim added a comment - Unfortunately, git symbolic-ref main refs/heads/main may allow master to stay pointing to where main does, but my experiments seem to show that it is not the equivalent of a real branch, and commands do not work identically: e.g. git checkout master gives "detached HEAD" state, and I suspect merges will also be problematic. Also, I believe that the symbolic ref is only local to a clone; it does not seem possible to make it mandatory for all new clones. If you are concerned about muscle memory typing the wrong branch name, you might try to use git checkout - or git switch - instead. It's shorter, and quite often what you want.
Hide

Can I request for a transition period, say a month or two, where both master and main branch names co-exist and the change of the default branch happens around the middle of this period? By this, I don't mean two different branches, but one single branch with an alias. I'm thinking along the lines of this Stack Overflow answer: https://stackoverflow.com/a/17236679

Show
Arun Kannawadi added a comment - Can I request for a transition period, say a month or two, where both master and main branch names co-exist and the change of the default branch happens around the middle of this period? By this, I don't mean two different branches, but one single branch with an alias. I'm thinking along the lines of this Stack Overflow answer:  https://stackoverflow.com/a/17236679
Hide
Eli Rykoff added a comment -

I support this, and I think that asking all the DM developers to help out on a concentrated day of action (if helpful) is reasonable. If conda-forge can make the mega-migration then we can too! (see recent updates at https://github.com/conda-forge/conda-forge.github.io/issues/1162 ).

Show
Eli Rykoff added a comment - I support this, and I think that asking all the DM developers to help out on a concentrated day of action (if helpful) is reasonable. If conda-forge can make the mega-migration then we can too! (see recent updates at https://github.com/conda-forge/conda-forge.github.io/issues/1162 ).
Hide
Frossie Economou added a comment -

As things stand right now:

• This has been discussed in various forums, I think it's clear there's support for the principle.
• Given the disruption of the implementation and various other timescales, implementation may not actually happen until December timeframe but that's the way with RFCs anyway
• Orgs that manage their own build chains (like lsst-sqre) can transition ahead of time if they wish.

Comments at variance with the above still welcome until RFC closes.

Show
Frossie Economou added a comment - As things stand right now: This has been discussed in various forums, I think it's clear there's support for the principle. Given the disruption of the implementation and various other timescales, implementation may not actually happen until December timeframe but that's the way with RFCs anyway Orgs that manage their own build chains (like lsst-sqre) can transition ahead of time if they wish.  Comments at variance with the above still welcome until RFC closes.
Hide
Russ Allbery added a comment -

Ah, thank you, I had not realized the default branch was already set on those organizations (I should have checked). That resolves my concern.

Show
Russ Allbery added a comment - Ah, thank you, I had not realized the default branch was already set on those organizations (I should have checked). That resolves my concern.

#### People

Assignee:
Frossie Economou
Reporter:
Frossie Economou
Watchers:
Andy Clements, Arun Kannawadi, Eli Rykoff, Eric Bellm, Frossie Economou, Gregory Dubois-Felsmann, John Parejko, Kian-Tat Lim, Lee Kelvin, Meredith Rawls, Russ Allbery, Russell Owen, Tim Jenness, Wouter van Reeven
1 Vote for this issue
Watchers:
14 Start watching this issue

#### Dates

Created:
Updated:
Resolved:
Planned End:

#### Jenkins

No builds found.