Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does `origin` have any special meaning_?

Tags:

git

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?

like image 369
cade galt Avatar asked Sep 06 '15 12:09

cade galt


1 Answers

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 remote master to origin, but forgot to create the origin branch ourselves.
Also it hardcoded the assumption that the remote HEAD 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 named origin/name-of-upstream-branch, which you can see using "git branch -r".

like image 80
VonC Avatar answered Oct 27 '22 00:10

VonC