Working through a few things while following along with @foamyguy from the Adafruit community, who was streaming some pull request reviews on YouTube, a few git "gotchas" were mentioned. A few of these have to do with the order of operations, others are a personal preference, so I thought I'd share the various configurations and commands used, and to help me remember when I next need it.
Depending on your personal workflow when working with a repository that isn't yours, you might or might not run into this issue. In this case, @foamyguy (and me, and others I know) run into this issue where we clone the original repository, hack away and do some work, commit and try to push our changes, only to realize, we're trying to push to a repository where we don't have access... or worse, where we DO have access (like the principal one), and mess things up for everyone. In this case, if we want to name our default remote something other than "origin", there are a few options...
Set the remote name when you clone it
git clone myownremote https://github.com/.....
This will name the remote "myownremote" instead of "origin"
Rename the remote after you clone it when you remember.
git remote rename origin montypython
This will rename the remote called "origin" for the current repository to "montypython".
Set the default remote name in git's configuration. WUT???
git config --global --clone.defaultRemoteName source
That's right, if you're not fond of the default name "origin", you can choose a default name that you prefer. So if you prefer to name your default remote "source", you can tell git to name it so by default.
Bonus Round - GitHub Edition!
If you use GitHub as your main repository, you can use their recently released command line tool, "gh". If you use their "repo" functionality with the "fork" verb, it will automatically perform the following tasks for you
- Create your own fork of the repository on GitHub
- Clone the repository to your local system
- Setup your fork on GitHub as "origin"
- Setup the original source as "upstream"
To do this for a project owned by the account called "projectowner" with the repository name "super-project", the command is this simple...
gh repo fork projectowner/super-project
Edit to add: I just happened to clone another repository using the GitHub CLI, using the
gh repo clone (since I didn't need a fork), and since it's ultimately using
git for any of git operations, if set your configuration as in step #3, your default remote name configuration will be applied.
Branches behave in a similar manner to remotes, but the syntax to change them is significantly different. But it's worth knowing how to name or rename them to how you want them.
Renaming an existing branch
git branch -m old-and-busted bugfix/This-shall-not-fail
In this case, we're calling the "move" (-m) command for branch "old-and-busted" and changing it to "bugfix/This-shall-not-fail". A way to help remember is that this follows the pattern to rename items in Unix and Linux based systems.
Giving it a name at checkout
git checkout -b feature/I-name-things-good
This will checkout a new branch called "I-name-things-good", based either on the current branch and commit (HEAD) where you are now or based on a branch in the remote with the same name if there is one based on the checkout.defaultRemote configuration value.
Greet it a nickname
git checkout -b ralph feature/I-name-things-good
What this will do is nearly a duplicate of option #2 above, with the exception that you're a) explicitly specifying a source branch, and b) explicitly naming your branch something different. In this case, we're checking out the branch identified as "feature/I-name-things-good" on the remote to our local repository with the name "ralph".
So those are the two major renaming activities that are done in git. Sure, there are others, but in my experience, the need to use them is so rare, I don't actually remember quite when the last time happened to be!