7 ms·

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

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.

culp 13y ago
I've generally considered trunk to be "upstream"
markberger 13y ago
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.
- steveklabnik 13y ago
  I use 'upstream' for this purpose.
- lambda 13y ago
  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.
  - js2 13y ago
    This is an excellent workflow and then one I use as well.
mataug 13y ago
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.
- ulisesrmzroche 13y ago
  Special circumstances being the common case of working in your own private branch? Kinda weird to make that big of a deal out of it.
js2 13y ago
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).

culp 13y ago

I've generally considered trunk to be "upstream"

markberger 13y ago

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.

steveklabnik 13y ago
I use 'upstream' for this purpose.
lambda 13y ago
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.
- js2 13y ago
  This is an excellent workflow and then one I use as well.

mataug 13y ago

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.

ulisesrmzroche 13y ago
Special circumstances being the common case of working in your own private branch? Kinda weird to make that big of a deal out of it.

js2 13y ago

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