Keeping track of all of the information about a remote repository reference can become tedious and difficult: you have to remember the full URL for the repository; you must type and retype remote references and refspecs on the command line each time you want to fetch updates; you have to reconstruct the branch mappings; and so on. Repeating the information is also likely to be quite error-prone.
You might also wonder how Git remembers the URL for the remote
from the initial clone for use in subsequent fetch or push operations
using origin.
Git provides three mechanisms for setting up and maintaining information about remotes: the git remote command, the git config command, and editing the .git/config file directly. All three mechanisms ultimately result in configuration information being recorded in the .git/config file.
The git remote command is a more specialized interface, specific to remotes, that manipulates the configuration file data. It has several subcommands with fairly intuitive names. There is no “help” option, but you can circumvent that to display a message with subcommand names via the “unknown subcommand trick”:
$ git remote xyzzy
error: Unknown subcommand: xyzzy
usage: git remote
or: git remote add <name> <url>
or: git remote rm <name>
or: git remote show <name>
or: git remote prune <name>
or: git remote update [group]
-v, --verbose be verboseYou saw the git remote add and
update commands in Make Your Own origin Remote, and
show in Adding a New Developer.
You used git remote add origin to add a new remote
named origin to the newly created parent repository
in the depot, and you ran the git remote show
origin command to extract all the information about the
remote origin. Finally, you used the git
remote update command to fetch all the updates available in
the remote repository into your local repository.
The command git remote rm removes the given remote and all its associated tracking branches from your local repository.
The remote repository may have branches deleted from it by the actions of other developers, even though your copies of them may linger in your repository. The prune command may be used to remove the names of those stale (with respect to the actual remote repository) tracking branches from your local repository.
The git config command can be used to manipulate the entries in your configuration file directly. This includes the several config variables for remotes.
For example, to add a new remote named
publish with a push refspec for all the branches
you would like to publish, you might do something like this:
$git config remote.publish.url 'ssh://git.example.org/pub/repo.git'$git config remote.publish.push '+refs/heads/*:refs/heads/*'
Each of the preceding commands adds a line to the
.git/config file. If no
publish remote section exists yet, the first
command you issue that refers to that remote creates a section in the
file for it. As a result, your .git/config
contains, in part, the following remote definition:
[remote "publish"]
url = ssh:git.example.com/pub/repo.git
push = +refs/heads/*:refs/heads/*Tip
Use the -l (lowercase L) option à la
git config -l to list the contents of the
configuration file with complete variable names:
# From a clone of git.git sources
$ git config -l
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=git://git.kernel.org/pub/scm/git/git.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/masterRather than wrestling with either the git remote or git config commands, directly editing the file with your favorite text editor may be easier or faster in some situations. There is nothing wrong with doing so, but it can be error-prone and is usually done only by developers who are very familiar with Git’s behavior and the configuration file. Yet having seen the parts of the file that influence various Git behaviors and the changes resulting from commands, you should have basis enough to understand and manipulate the configuration file.