I've setup a few github repos using this documentation:
echo "# foo" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/foo-1/foo.git
git push -u origin master
Does the name origin
have any special meaning?
If so is it purely semantical?
It is now just the default name for the cloned upstream repo.
But it used to be a branch as well originally (up until git 1.5.0 in early 2007):
The very first commit introducing 'origin
' dates from 1cadb5a (July 2005, git 0.99.2).
It is followed by commit a692b96, which explained:
A recommended work cycle for an "individual developer" who does not have a "public" repository is somewhat different. It goes like this:
(1) Prepare your work repository, by "
git clone
" the public repository of the "project lead" (or a "subsystem maintainer", if you work on a subsystem).
The URL used for the initial cloning is stored in.git/branches/origin
.(2) Do your work there. Make commits.
(3) Run "
git fetch origin
" from the public repository of your upstream every once in a while. This does only the first half of "git pull" but does not merge.
The head of the public repository is stored in.git/refs/heads/origin
.
That workflow was obviously very much tailored to the distributed development of the Linux kernel, in which you had only one upstream repo.
The .git/branches/origin
won't become .git/remotes/origin
before commit 6687f8f (Aug. 2005, git v0.99.5), when you can fetch more than one upstream repo.
Now multi-head fetch is complete, let's migrate the default configuration for new repositories created with the "
git clone
" command.The original
$GIT_DIR/branches
is not deprecated yet, but create remotes directory by default from the templates as well.
Then commit e125c1a (Nov. 2005, v0.99.9c) added:
The newly cloned repository by default had
.git/remotes/origin
set up to track the remotemaster
toorigin
, but forgot to create theorigin
branch ourselves.
Also it hardcoded the assumption that the remoteHEAD
points at "master
", which may not always be true.
It started to evolve to 'origin' as an upstream repo in commit dfeff66 (March 2006, git 1.3.0), where:
The upstream branch heads are copied in
.git/refs/remotes/
instead of.git/refs/heads/
and.git/remotes/origin
file is set up to reflect this as well.
It requires to have fetch/pull update to understand.git/refs/remotes
by Eric Wong to further update the repository cloned this way.
This is detailed in commit c72112e.
Defaulting to 'origin' when fetching was introduced in commit 5e27e27 (July 2006, git 1.4.2).
The remote origin
is stored in ./git/config
in commit 255cae8 (Nov. 2006, git 1.5.0)
For example what was previously
.git/remotes/origin
:
URL: proto://host/path
Pull: refs/heads/master:refs/heads/origin
Is now added to
.git/config
as:
[remote "origin"]
url = proto://host/path
fetch = refs/heads/master:refs/heads/origin
git pull
defaults to origin
with commit 955289b (Dec. 2006, git 1.5.0):
Without any specification in the .git/config
file, git-pull
will execute
"git-pull origin
"; which in turn defaults to pull from the first "pull"
definition for the remote, "origin
".
The glossary is then updated:
origin
:The default upstream repository. Most projects have at least one upstream project which they track. By default '
origin
' is used for that purpose.
New upstream updates will be fetched into remote tracking branches namedorigin/name-of-upstream-branch
, which you can see using "git branch -r
".
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With