I am experimenting with git and have created a repository in ~/A containing only a master branch.
I have then cloned this repository into ~/B (by starting a git daemon in ~/A and running git clone git://127.0.0.1/).
I then created a new test branch in ~/A and tried to get that branch in ~/B. However, git fetch git://127.0.0.1/ only showed
From git://127.0.0.1
* branch HEAD -> FETCH_HEAD
To get the new branch I ended up doing git fetch, which as far as I understand is equivalent to git fetch origin. In any case, both of these give me
From git://127.0.0.1
* [new branch] test -> origin/test
after which I can start working on the test branch in ~/B by doing git checkout test.
How is it possible that git fetch git://127.0.0.1/ and git fetch origin have different results, when git remote -v shows
origin git://127.0.0.1/ (fetch)
origin git://127.0.0.1/ (push)
The daemon shows the same request for all commands, namely
[20291] Extended attribute "host": 127.0.0.1
[20291] Request upload-pack for '/'
When you run git fetch origin you are asking git to look up the configuration for your remote named origin, fetch from the configured URL and write any fetchspec mapping to store the remote’s information in remote tracking branches (eg mapping your refs/remotes/origin/master to the remote’s refs/heads/master).
When you run git fetch <url>, you bypass the remote configuration. git does not try to match the url to a remote and use the remote configuration. (Indeed that would be ambiguous, you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs).
Instead, git fetch <url> will fetch from the specified url directly, and put the remote’s HEAD into your FETCH_HEAD file. Since there is no remote, it does not update remote tracking branches. You can inspect FETCH_HEAD to see what you’ve fetched, however it’s much easier to fetch with a remote instead of a url.