Allow use of `main` as primary branch in edge cases like migrate

[pboling]

🚀 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.

[patrickleet]

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

meta git checkout master

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

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[patrickleet]

@rikkit has a simple version of using main in his branch of meta project mateodelnorte/meta-project#95

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[emahuni]

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 this master | main issue is solvable by not constraining what a user can do with git, 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.