Does `origin` have any special meaning_?

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?

  • How does one clone a git repository with only a non-master branch?
  • GitHub - HTTPS access
  • How do you allow multiple people to push to github?
  • Understanging Conflicts Merging Algorithm
  • How to tell Git to always pull the master branch?
  • Fatal: The remote end hung up unexpectedly
  • If so is it purely semantical?

  • Integrating MsBuild with Git
  • With “git svn”, Can I Ignore Specific Git Commits While Fetching?
  • Git as mercurial client? Why no git-hg?
  • git: simplest way to share a repository between two laptops on a local network?
  • how does git handle merging code that was moved to a different file?
  • Git cancel a revert
  • One Solution collect form web for “Does `origin` have any special meaning_?”

    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“.

    Git Baby is a git and github fan, let's start git clone.