What's the difference between `git fetch origin` and `git fetch git://127.0.0.1/`
up vote
2
down vote
favorite
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 '/'
git git-remote git-fetch
asked Nov 11 at 7:33
Bananach
374114
add a comment |
up vote
2
down vote
favorite
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 '/'
git git-remote git-fetch
asked Nov 11 at 7:33
Bananach
374114
Your Git URL does not look correct, see here. I think it should be ending in.git.
– Tim Biegeleisen
Nov 11 at 7:42
@TimBiegeleisen I got that part from gist.github.com/RichardBronosky/… Note thatgit clone git://127.0.0.1/does not cause any problem
– Bananach
Nov 11 at 8:44
@TimBiegeleisen It's not required that the URL ends in.git. That's only a convention.
– David Z
Nov 11 at 11:28
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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 '/'
git git-remote git-fetch
asked Nov 11 at 7:33
Bananach
374114
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 '/'
git git-remote git-fetch
git git-remote git-fetch
asked Nov 11 at 7:33
Bananach
374114
asked Nov 11 at 7:33
Bananach
374114
edited Nov 11 at 11:23
asked Nov 11 at 7:33
Bananach
374114
asked Nov 11 at 7:33
Bananach
374114
asked Nov 11 at 7:33
Bananach
374114
374114
Your Git URL does not look correct, see here. I think it should be ending in.git.
– Tim Biegeleisen
Nov 11 at 7:42
@TimBiegeleisen I got that part from gist.github.com/RichardBronosky/… Note thatgit clone git://127.0.0.1/does not cause any problem
– Bananach
Nov 11 at 8:44
@TimBiegeleisen It's not required that the URL ends in.git. That's only a convention.
– David Z
Nov 11 at 11:28
add a comment |
Your Git URL does not look correct, see here. I think it should be ending in.git.
– Tim Biegeleisen
Nov 11 at 7:42
@TimBiegeleisen I got that part from gist.github.com/RichardBronosky/… Note thatgit clone git://127.0.0.1/does not cause any problem
– Bananach
Nov 11 at 8:44
@TimBiegeleisen It's not required that the URL ends in.git. That's only a convention.
– David Z
Nov 11 at 11:28
Your Git URL does not look correct, see here. I think it should be ending in
.git.– Tim Biegeleisen
Nov 11 at 7:42
Your Git URL does not look correct, see here. I think it should be ending in
.git.– Tim Biegeleisen
Nov 11 at 7:42
@TimBiegeleisen I got that part from gist.github.com/RichardBronosky/… Note that
git clone git://127.0.0.1/ does not cause any problem– Bananach
Nov 11 at 8:44
@TimBiegeleisen I got that part from gist.github.com/RichardBronosky/… Note that
git clone git://127.0.0.1/ does not cause any problem– Bananach
Nov 11 at 8:44
@TimBiegeleisen It's not required that the URL ends in
.git. That's only a convention.– David Z
Nov 11 at 11:28
@TimBiegeleisen It's not required that the URL ends in
.git. That's only a convention.– David Z
Nov 11 at 11:28
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
2
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessedgit remote -vshows me all there is to know about remotes but as mentioned in the question this command only shows URLs
– Bananach
Nov 11 at 11:14
That's a good question - I don't see an obvious easy command to do it; you can rungit config --get-all remote.origin.fetch. (I would have expected agit remotecommand but I don't see one.)
– Edward Thomson
Nov 11 at 12:43
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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.
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
2
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessedgit remote -vshows me all there is to know about remotes but as mentioned in the question this command only shows URLs
– Bananach
Nov 11 at 11:14
That's a good question - I don't see an obvious easy command to do it; you can rungit config --get-all remote.origin.fetch. (I would have expected agit remotecommand but I don't see one.)
– Edward Thomson
Nov 11 at 12:43
add a comment |
up vote
2
down vote
accepted
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.
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
2
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessedgit remote -vshows me all there is to know about remotes but as mentioned in the question this command only shows URLs
– Bananach
Nov 11 at 11:14
That's a good question - I don't see an obvious easy command to do it; you can rungit config --get-all remote.origin.fetch. (I would have expected agit remotecommand but I don't see one.)
– Edward Thomson
Nov 11 at 12:43
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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.
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
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.
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
answered Nov 11 at 9:03
Edward Thomson
48.1k9101141
48.1k9101141
2
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessedgit remote -vshows me all there is to know about remotes but as mentioned in the question this command only shows URLs
– Bananach
Nov 11 at 11:14
That's a good question - I don't see an obvious easy command to do it; you can rungit config --get-all remote.origin.fetch. (I would have expected agit remotecommand but I don't see one.)
– Edward Thomson
Nov 11 at 12:43
add a comment |
2
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessedgit remote -vshows me all there is to know about remotes but as mentioned in the question this command only shows URLs
– Bananach
Nov 11 at 11:14
That's a good question - I don't see an obvious easy command to do it; you can rungit config --get-all remote.origin.fetch. (I would have expected agit remotecommand but I don't see one.)
– Edward Thomson
Nov 11 at 12:43
2
2
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessed
git remote -v shows me all there is to know about remotes but as mentioned in the question this command only shows URLs– Bananach
Nov 11 at 11:14
You say "you can have multiple remotes with the same URL, which might be useful for configuring different fetch specs". Where can I investigate these "fetch specs"? I would have guessed
git remote -v shows me all there is to know about remotes but as mentioned in the question this command only shows URLs– Bananach
Nov 11 at 11:14
That's a good question - I don't see an obvious easy command to do it; you can run
git config --get-all remote.origin.fetch. (I would have expected a git remote command but I don't see one.)– Edward Thomson
Nov 11 at 12:43
That's a good question - I don't see an obvious easy command to do it; you can run
git config --get-all remote.origin.fetch. (I would have expected a git remote command but I don't see one.)– Edward Thomson
Nov 11 at 12:43
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53246722%2fwhats-the-difference-between-git-fetch-origin-and-git-fetch-git-127-0-0-1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Your Git URL does not look correct, see here. I think it should be ending in
.git.– Tim Biegeleisen
Nov 11 at 7:42
@TimBiegeleisen I got that part from gist.github.com/RichardBronosky/… Note that
git clone git://127.0.0.1/does not cause any problem– Bananach
Nov 11 at 8:44
@TimBiegeleisen It's not required that the URL ends in
.git. That's only a convention.– David Z
Nov 11 at 11:28