Why do git reset & push use slashes vs spaces between remote and branchname?

Question

A hard git reset is often used after a force push or forced update to copy all remote changes of a branch. For example after a rebase and a force push with

git push --force origin my_branch

your team member can use

git reset --hard origin/my_branch

to get the updated branch. The question is why do you have to specify a slash / for git reset, but not for git push ?

Answer 1

Why the / ?

In git push <remote> <branch> you are giving two parameters: the remote name and the branch name. Hence no reason to add a /. The remote is an essential part here; after all, push will communicate with it.

In git reset ... origin/my_branch you are giving one parameter: the name of a branch. In this context, origin/my_branch is the name of the branch, fully specified. You could also give the name of a local branch here (in which case you would leave off the .../ part. So if there were a space in between (instead of using the fully qualified branch name), it would become quite confusing and error prone. reset does not care about or even know about remotes.

Careful

git reset --hard origin/my_branch

This needs a git checkout my_branch first or you will reset whatever other branch you are currently on. You might want to edit your question so people who stumble across it don't get the wrong impression.

Keep their changes

More importantly, there is no need to do a hard reset (i.e. to throw away all locally committed changes on the branch) after a rebase was force-pushed. Your colleagues can simply do the same rebase operation on their end, and then everything is fine again (well, not in pathologigal cases with lots and lots of conflicts, of course). The "rerere cache" can help here (see git help rerere).

So, if you did:

git checkout my_branch
git rebase abc12345
git push --force

Then they can do:

git fetch   # in case they do not have abc12345 yet
git checkout my_branch
git rebase abc12345
git pull

The rebase operation is repeatable, so this should work well, usually. This will let the other developers keep all their local changes and get yours on top (remember that the pull is basically a merge).

Answer 2

This is more of a long comment rather then a proper answer.

I suppose generic answer to this would be something like:

"it has been programmed that way"

On a more serious note, perhaps it has something to do with the resources and their location. What I mean by resources here is local or remote.

Let's look at the two commands you've mentioned in your original post.

git push -f <remote> <branch>

So what does push actually do? Simplistically it takes whatever you've got on your local repository and pushes it upstream to the remote repository. How would we do that? From design perspective, if you think about it, it makes a perfect sense to pass two parameters in this case a remote a place where you will send your changes and branch from your local system which you will be preserving long-term.

Next, let's look at

git reset --hard <remote>/<branch>

This instruction basically resets your working directory to whichever index you specify. Also, note this is all done from your local file system and this is the difference between the two commands you've brought up in your OP.

Answer 3

The git push command first takes a remote parameter, where you specify the repo you're pushing to followed by the local branch ref to update the corresponding remote branch with.

git reset, however, takes a single path parameter where you are specifying the branch of the remote repo (via a path) to reset the local copy to.

To answer your question directly, the reason you need a slash for git reset is because it takes one parameter which is a path rather than git push which takes two separate parameters: a remote and a branch.

You may wish to refer to git push and git reset official documentation for Git.