Jocko Homo
Jocko Homo

Reputation: 175

Git: What's the difference between fetching from named remote and fetching from a URL?

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

Answers (2)

Jakub Narębski
Jakub Narębski

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

Simon Boudrias
Simon Boudrias

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

Related Questions