Allow use of `main` as primary branch in edge cases like migrate
See original GitHub issue🚀 Feature Proposal
Github now defaults to main
for new repositories. I’d like to be able to use meta
with those repositories. A hybrid approach seems ideal so we don’t have to touch legacy repos, so it could work with both main
and master
. Perhaps it could detect the primary branch name? Or use a preset list of fallbacks, like:
main
master
Motivation
When creating a new repository on Github via the UI the default branch is now main
, which doesn’t work with meta
.
Example
For a new repository, attempting to add it to a meta repo I get this error:
fatal: Remote branch master not found in upstream origin
I’d like to be able to do this:
meta project import projects/the-project git@giturl
and have it work regardless of the primary branch name.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7
Top Results From Across the Web
5 steps to change GitHub default branch from master to main
Step 1 - Move the 'master' branch to 'main'. Run the following command which creates a branch called 'main' using the history from...
Read more >Why GitHub renamed its master branch to main | TheServerSide
GitHub renamed the master branch to main for any Git repository, as it addresses cultural change like so many organizations that have nixed ......
Read more >Configure git to use 'main' as the primary branch
Change REMOTENAME to the name of your remote repository. Run git remote to view existing remotes.
Read more >Default branch - GitLab Docs
On the top bar, select Main menu > Admin. On the left sidebar, select Settings > Repository. Expand Default branch. Select Initial default...
Read more >Stop Using Branches for Deploying to Different GitOps ...
You should NOT use Git branches for modeling different environments. If the Git repository holding your configuration (manifests/templates in ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
if some repos use main, and some master, you’re gonna have other problems as well, such as scripting checking out the repos, as for that command you specify which branch you are checking out, and a mixed bag will just fail on half of them
for example
or rebasing
so it’s better to use one or the other - that said - I don’t know a good solution to this at the moment - maybe a project level config that meta can look at and use
why not just pass everything to the executable when the command is not in the plugin and let the executable complain if there are any errors?
If I say
meta git blah
, the meta-git plugin should send that blah as a command it doesn’t know to git, eg:git blah
. Probably blah is now a new command that this plugin never knew about. The idea here is that any new conventions are covered and this future proofs the Meta lib and its related plugin. So thismaster
|main
issue is solvable by not constraining what a user can do withgit
, meta git should simply handle custom commands / overrides and then pass on any weird unknown ones to git.a simple example here is
Meta plugin is trying to work on every command, why not let git/yarn (in this case) do it? everything else it doesn’t know just ends up as silent. I think this is where that forwarding needs to happen.