path: root/Documentation/git-remote.txt
AgeCommit message (Collapse)Author
2020-10-27remote: add meaningful exit code on missing/existingÆvar Arnfjörð Bjarmason
Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2020-10-08doc: git-remote fix upsJean-Noël Avila
Signed-off-by: Jean-Noël Avila <> Signed-off-by: Junio C Hamano <>
2019-04-02doc: promote "git switch"Nguyễn Thái Ngọc Duy
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-06-04Merge branch 'nd/remote-update-doc'Junio C Hamano
"git remote update" can take both a single remote nickname and a nickname for remote groups, but only one of them was documented. * nd/remote-update-doc: remote: doc typofix remote.txt: update documentation for 'update' command
2018-06-04remote: doc typofixDuy Nguyen
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-06-01remote.txt: update documentation for 'update' commandDuy Nguyen
Commit b344e1614b (git remote update: Fallback to remote if group does not exist - 2009-04-06) lets "git remote update" accept individual remotes as well. Previously this command only accepted remote groups. The commit updates the command syntax but not the actual document of this subcommand. Update it. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-02doc: keep first level section header in upper caseNguyễn Thái Ngọc Duy
When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-02-09git remote doc: correct dangerous lies about what prune doesÆvar Arnfjörð Bjarmason
The "git remote prune <name>" command uses the same machinery as "git fetch <name> --prune", and shares all the same caveats, but its documentation has suggested that it'll just "delete stale remote-tracking branches under <name>". This isn't true, and hasn't been true since at least v1.8.5.6 (the oldest version I could be bothered to test). E.g. if "refs/tags/*:refs/tags/*" is explicitly set in the refspec of the remote, it'll delete all local tags <name> doesn't know about. Instead, briefly give the reader just enough of a hint that this option might constitute a shotgun aimed at their foot, and point them to the new PRUNING section in the git-fetch documentation which explains all the nuances of what this facility does. See "[BUG] git remote prune removes local tags, depending on fetch config" ( by Michael Giuffrida for the initial report. Reported-by: Michael Giuffrida <> Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2016-06-28doc: typeset long command-line options as literalMatthieu Moy
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2015-10-29Merge branch 'xf/user-manual-markup'Junio C Hamano
AsciiDoc markup fixes. * xf/user-manual-markup: Documentation: match undefline with the text in old release notes Documentation: match underline with the text Documentation: fix header markup
2015-10-22Documentation: match underline with the textJunio C Hamano
Even though AsciiDoc is more lenient when deciding if an underline is for the contents on the previous line to find section headers, we should match the length of them for other formatters to help them. Signed-off-by: Junio C Hamano <>
2015-09-17remote: add get-url subcommandBen Boeckel
Expanding `insteadOf` is a part of ls-remote --url and there is no way to expand `pushInsteadOf` as well. Add a get-url subcommand to be able to query both as well as a way to get all configured urls. Signed-off-by: Ben Boeckel <> Signed-off-by: Junio C Hamano <>
2015-03-06Merge branch 'mg/doc-remote-tags-or-not'Junio C Hamano
"git remote add" mentioned "--tags" and "--no-tags" and was not clear that fetch from the remote in the future will use the default behaviour when neither is given to override it. * mg/doc-remote-tags-or-not: git-remote.txt: describe behavior without --tags and --no-tags
2015-03-02git-remote.txt: describe behavior without --tags and --no-tagsMichael J Gruber
Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2015-01-29Documentation/git-remote.txt: stress that set-url is not for triangularJunio C Hamano
It seems to be a common mistake to try using a single remote (e.g. 'origin') to fetch from one place (i.e. upstream) while pushing to another (i.e. your publishing point). That will never work satisfactorily, and it is easy to understand why if you think about what refs/remotes/origin/* would mean in such a world. It fundamentally cannot reflect the reality. If it follows the state of your upstream, it cannot match what you have published, and vice versa. It may be that misinformation is spread by some people. Let's counter them by adding a few words to our documentation. - The description was referring to <oldurl> and <newurl>, but never mentioned <name> argument you give from the command line. By mentioning "remote <name>", stress the fact that it is configuring a single remote. - Add a reminder that explicitly states that this is about a single remote, which the triangular workflow is not about. Signed-off-by: Junio C Hamano <>
2014-02-11docs/git-remote: capitalize first word of initial blurbAlbert L. Lash, IV
All other man files have capitalized descriptions which immediately follow the command's name. Let's capitalize this one too for consistency. Signed-off-by: Albert L. Lash, IV <> Signed-off-by: Junio C Hamano <>
2013-09-27remote doc: document long forms of set-head optionsPhilip Oakley
"git remote set-head" has always supported --add and --delete as synonyms for the -a and -d option but forgot to document them. Signed-off-by: Philip Oakley <> Signed-off-by: Jonathan Nieder <>
2013-06-23Documentation: Update the NFS remote examples to use the staging repoW. Trevor King seems to have restructured their repository layout since 8391c60 (git-remote.txt: fix example url, 2007-11-02), and Bruce's repo is now at git:// Bruce also has a more richer internal branch structure (master, everything, for-3.1, ...), so updating the existing example to use his current repo may be confusing. To simplify, I've replaced the NFS repo with Greg's staging repo. I've also updated the output of the surrounding commands to match the output of a current run through. Signed-off-by: W. Trevor King <> Signed-off-by: Junio C Hamano <>
2013-05-17documentation: trivial style cleanupsFelipe Contreras
White-spaces, missing braces, standardize --[no-]foo. Signed-off-by: Felipe Contreras <> Signed-off-by: Junio C Hamano <>
2013-04-24remote: 'show' and 'prune' can take more than one remoteThomas Rast
The 'git remote show' and 'prune' subcommands are documented as taking only a single remote name argument, but that is not the case; they will simply iterate the action over all remotes given. Update the documentation and tests to match. With the last user of the -f flag gone, we also remove the code supporting it. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2012-09-06remote: prefer subcommand name 'remove' to 'rm'Nguyễn Thái Ngọc Duy
All remote subcommands are spelled out words except 'rm'. 'rm', being a popular UNIX command name, may mislead users that there are also 'ls' or 'mv'. Use 'remove' to fit with the rest of subcommands. 'rm' is still supported and used in the test suite. It's just not widely advertised. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-04-26docs: stop using asciidoc no-inline-literalJeff King
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <>` used to erroneously auto-generate a mailto footnote for - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-02-23Merge branch 'pj/remote-set-branches-usage-fix'Junio C Hamano
* pj/remote-set-branches-usage-fix: remote: fix set-branches usage and documentation Conflicts: builtin/remote.c
2012-02-20remote: fix set-branches usage and documentationPhilip Jägenstedt
The canonical order of command line arguments is always to have dashed commands before other parameters, but the "git remote set-branches" subcommand was described to take "name" before an optional "--add". Signed-off-by: Philip Jägenstedt <> Signed-off-by: Junio C Hamano <>
2011-06-23git-remote.txt: avoid sounding as if loose refs are the only ones in the worldJunio C Hamano
It was correct to say "The file $GIT_DIR/refs/heads/master stores the commit object name at the tip of the master branch" in the older days, but not anymore, as refs can be packed into $GIT_DIR/packed-refs file. Update the document to talk in terms of a more abstract concept "ref" and "symbolic ref" where we are not describing the underlying implementation detail. This on purpose leaves two instances of $GIT_DIR/ in the git-remote documentation; they do talk about $GIT_DIR/remotes/ and $GIT_DIR/branches/ file hierarchy that used to be the place to store configuration around remotes before the configuration mechanism took them over. Signed-off-by: Junio C Hamano <>
2011-06-23git-remote.txt: fix wrong remote refspecNamhyung Kim
$GIT_DIR/remotes/<name>/<branch> should be $GIT_DIR/refs/remotes/<name>/<branch>. Signed-off-by: Namhyung Kim <> Signed-off-by: Junio C Hamano <>
2011-04-06Merge branch 'jk/maint-remote-mirror-safer'Junio C Hamano
* jk/maint-remote-mirror-safer: remote: deprecate --mirror remote: separate the concept of push and fetch mirrors remote: disallow some nonsensical option combinations
2011-03-30remote: deprecate --mirrorJeff King
The configuration created by plain --mirror is dangerous and useless, and we now have --mirror=fetch and --mirror=push to replace it. Let's warn the user. One alternative to this is to try to guess which type the user wants. In a non-bare repository, a fetch mirror doesn't make much sense, since it would overwrite local commits. But in a bare repository, you might use either type, or even both (e.g., if you are acting as an intermediate drop-point across two disconnected networks). So rather than try for complex heuristics, let's keep it simple. The user knows what they're trying to do, so let them tell us. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-03-30remote: separate the concept of push and fetch mirrorsJeff King
git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-03-11doc: drop author/documentation sections from most pagesJeff King
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2010-11-03Change "tracking branch" to "remote-tracking branch"Matthieu Moy
One more step towards consistancy. We change the documentation and the C code in a single patch, since the only instances in the C code are in comment and usage strings. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-11-03Replace "remote tracking" with "remote-tracking"Matthieu Moy
"remote-tracking" branch makes it explicit that the branch is "tracking a remote", as opposed to "remote, and tracking something". See discussion in e.g. for more details. This patch is a straightforward application of perl -pi -e 's/remote tracking branch/remote-tracking branch/' except in the RelNotes directory. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-10-08Use parentheses and `...' where appropriateŠtěpán Němec
Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec <> Acked-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-10-08Use angles for placeholders consistentlyŠtěpán Němec
Signed-off-by: Štěpán Němec <> Acked-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-06-18Merge branch 'jn/remote-set-branches'Junio C Hamano
* jn/remote-set-branches: Add git remote set-branches Conflicts: builtin/remote.c
2010-05-20Add git remote set-branchesJonathan Nieder
Add ‘git remote set-branches’ for changing the list of tracked refs for a remote repository with one "porcelain-level" command. This complements the longstanding ‘git remote add --track’ option. The interface is based on the ‘git remote set-url’ subcommand. git remote set-branches base --add C git remote set-branches base A B D git remote set-branches base --delete D; # not implemented Suggested-by: martin f. krafft <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-04-19remote add: add a --[no-]tags optionSamuel Tardieu
Add '--[no-]tags' options to 'git remote add' which add the 'remote.REMOTE.tagopt = --[no-]tags' to the configuration file. This mimics the "--tags" and "--no-tags" options of "git fetch". Signed-off-by: Samuel Tardieu <> Signed-off-by: Junio C Hamano <>
2010-01-23Merge branch 'il/remote-updates'Junio C Hamano
* il/remote-updates: Add git remote set-url
2010-01-19Add git remote set-urlIlari Liusvaara
Add 'git remote set-url' for changing URL of remote repository with one "porcelain-level" command. Signed-off-by: Ilari Liusvaara <> Signed-off-by: Junio C Hamano <>
2010-01-10Documentation: spell 'git cmd' without dash throughoutThomas Rast
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2009-11-21git remote: Separate usage strings for subcommandsTim Henigan
When the usage string for a subcommand must be printed, only print the information relevant to that command. This commit also removes the complete options list from the first line of the subcommand usage string. Instead, individual options are documented in the detailed description following the general usage line. Signed-off-by: Tim Henigan <> Signed-off-by: Junio C Hamano <>
2009-08-11Fix typos in git-remote.txt and git-symbolic-ref.txtŠtěpán Němec
Signed-off-by: Štěpán Němec <> Signed-off-by: Junio C Hamano <>
2009-04-08git remote update: Fallback to remote if group does not existFinn Arne Gangstad
Previously, git remote update <remote> would fail unless there was a remote group configured with the same name as the remote. git remote update will now fall back to using the remote if no matching group can be found. This enables "git remote update -p <remote>..." to fetch and prune one or more remotes, for example. Signed-off-by: Finn Arne Gangstad <> Signed-off-by: Junio C Hamano <>
2009-04-05git remote update: New option --pruneFinn Arne Gangstad
With the --prune (or -p) option, git remote update will also prune all the remotes that it fetches. Previously, you had to do a manual git remote prune <remote> for each of the remotes you wanted to prune, and this could be tedious with many remotes. A single command will now update a set of remotes, and remove all stale branches: git remote update -p [group] Signed-off-by: Finn Arne Gangstad <> Signed-off-by: Junio C Hamano <>
2009-02-27builtin-remote: add set-head subcommandJay Soffian
Provide a porcelain command for setting and deleting $GIT_DIR/remotes/<remote>/HEAD. While we're at it, document what $GIT_DIR/remotes/<remote>/HEAD is all about. Signed-off-by: Jay Soffian <> Signed-off-by: Junio C Hamano <>
2008-11-12git-remote: document the migration feature of the rename subcommandMiklos Vajna
Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>
2008-11-05Implement git remote renameMiklos Vajna
The new rename subcommand does the followings: 1) Renames the configuration section to 2) Updates the refspecs 3) Updates the branch.*.remote settings 4) Renames the tracking branches: renames the normal refs and rewrites the symrefs to point to the new refs. Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>
2008-07-05manpages: italicize command names in synopsesJonathan Nieder
To tell command names from options in a glance. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-07-05Documentation: more "git-" versus "git " changesJonathan Nieder
With git-commands moving out of $(bindir), it is useful to make a clearer distinction between the git subcommand 'git-whatever' and the command you type, `git whatever <options>`. So we use a dash after "git" when referring to the former and not the latter. I already sent a patch doing this same thing, but I missed some spots. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation: be consistent about "git-" versus "git "Jonathan Nieder
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>