Reputation: 175
Suppose I clone a git repository from the path /path/to/repo
. The original repository will be a remote called "origin". I can fetch objects from the origin with the command git fetch origin
. This will retrieve all the objects from the remote "origin", including any branches made.
What's curious is that if I explicitly fetch from that same repository with the command git fetch /path/to/repo
, I appear to retrieve all of the commit objects but not any of the branches.
Why is that? Am I not doing exactly the same thing in both cases? How can Git's behavior be so different?
Upvotes: 5
Views: 198
Reputation: 323374
The major difference is that fetching from an URL doesn't store state of branches in remote repository into remote-tracking branches (e.g. refs/heads/master
i.e. master
branch in remote origin
into refs/remotes/origin/master
aka origin/master
) but only in FETCH_HEAD
.
Using URL instead of setting up remote via git remote add
is used in one-off pulls i.e.:
$ git pull <URL> <branch or tag>
Upvotes: 2
Reputation: 44589
Named remote use their configuration where they setup a refspec
schema when this remote is fetched:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /path/to/repo
So, these two format are equivalent:
git fetch origin
git fetch /path/to/repo +refs/heads/*:refs/remotes/origin/*
Basically: git fetch <path> <source>:<destination>
. And the destination is important here because it's where the remote HEAD and branches pointer are stored.
By doing git fetch /path/to/repo
, you don't set any refspec. As so, it only fetches the commits, not the objects because git
hasn't been instructed to get and store them.
There may be some details or naming convention incorrect here, feel free to edit. But the global idea should be correct
Upvotes: 5