Trunk is normally called origin in git nomenclature.
git push -f needs a big red box round it, not as a normal thing to do.
If you want to fix a pushed commit, do a new commit! If you keep pushing dodgy commits, try waiting between committing and pushing, or get better at reviewing your changes.
Trunk is normally called origin in git nomenclature.
Pedantically, when you refer to "origin", you're referring to the default branch for the remote named "origin" (i.e. the branch referred to by refs/remotes/origin/HEAD after cloning).
This is typically master, but not necessarily. In fact, you can update refs/remotes/origin/HEAD to point to any branch under refs/remotes/origin via "git remote set-head". (It's also possible that the remote repo's HEAD was something other than master when you cloned.)
If you want to be explicit, use origin/master, or refs/remotes/origin/master to be more explicit still.
The same applies for other remotes you may have configured in the same repo.
A related concept is the @{u}/@{upstream} token. Git resolves this token from the currently checked-out branch's configuration. e.g., if master is checked out (i.e. HEAD is refs/heads/master), git checks in .git/config for branch.master.remote and branch.master.merge and uses those to determine the upstream branch. In this example, those would typically be branch.master.remote=origin and branch.master.merge=refs/heads/master, which git resolves to refs/remotes/origin/master.
Finally, @{upstream} can be configured via git branch --set-upstream-to=... (in older versions of git the more confusing and now deprecated --set-upstream was used).
Thanks for the comments Richard. Since Github uses origin as user's fork of the project, I was trying to distinguish the project's main repository and the user's fork. Admittedly, after seeing comments from other people, trunk probably isn't the best name for it.
My convention is usually to clone from the upstream project, thus it winds up being "origin", and then adding my own repository as another remote, named after my username. If there are any other users whose repositories I'm following, I add theirs as other remotes named after their usernames as well, remaining consistent.
That way, when I pull from origin, I'm pulling from whatever the official origin repository is; when I pull from another named repo, it's named after whose repo it is.
It's also frequently the case that I've cloned from upstream before ever forking the repo on GitHub. It's only once I have any changes I need to make that I create a fork and add my own remote.
Agreed, git push -f has caused a lot of grief because of git newbies. So in my workplace its considered a cardinal sin except under some special circumstances. It needs a really big RED box around it.
git push -f needs a big red box round it, not as a normal thing to do.
If you want to fix a pushed commit, do a new commit! If you keep pushing dodgy commits, try waiting between committing and pushing, or get better at reviewing your changes.