summaryrefslogtreecommitdiff
path: root/Documentation/git-remote.txt
AgeCommit message (Collapse)AuthorFilesLines
2022-03-03builtin/remote.c: show progress when renaming remote referencesLibravatar Taylor Blau1-1/+1
When renaming a remote, Git needs to rename all remote tracking references to the remote's new name (e.g., renaming "refs/remotes/old/foo" to "refs/remotes/new/foo" when renaming a remote from "old" to "new"). This can be somewhat slow when there are many references to rename, since each rename is done in a separate call to rename_ref() as opposed to grouping all renames together into the same transaction. It would be nice to execute all renames as a single transaction, but there is a snag: the reference transaction backend doesn't support renames during a transaction (only individually, via rename_ref()). The reasons there are described in more detail in [1], but the main problem is that in order to preserve the existing reflog, it must be moved while holding both locks (i.e., on "oldname" and "newname"), and the ref transaction code doesn't support inserting arbitrary actions into the middle of a transaction like that. As an aside, adding support for this to the ref transaction code is less straightforward than inserting both a ref_update() and ref_delete() call into the same transaction. rename_ref()'s special handling to detect D/F conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F conflicts when renaming a reference during a transaction. The reftable backend could support this much more readily because of its lack of D/F conflicts. Instead of a more complex modification to the ref transaction code, display a progress meter when running verbosely in order to convince the user that Git is doing work while renaming a remote. This is mostly done as-expected, with the minor caveat that we intentionally count symrefs renames twice, since renaming a symref takes place over two separate calls (one to delete the old one, and another to create the new one). [1]: https://lore.kernel.org/git/572367B4.4050207@alum.mit.edu/ Suggested-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09doc: uniformize <URL> placeholders' caseLibravatar Jean-Noël Avila1-4/+4
URL being an acronym, it deserves to be kept uppercase. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27remote: add meaningful exit code on missing/existingLibravatar Ævar Arnfjörð Bjarmason1-0/+11
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: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08doc: git-remote fix upsLibravatar Jean-Noël Avila1-10/+10
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02doc: promote "git switch"Libravatar Nguyễn Thái Ngọc Duy1-1/+1
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-04Merge branch 'nd/remote-update-doc'Libravatar Junio C Hamano1-2/+2
"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 typofixLibravatar Duy Nguyen1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01remote.txt: update documentation for 'update' commandLibravatar Duy Nguyen1-2/+2
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02doc: keep first level section header in upper caseLibravatar Nguyễn Thái Ngọc Duy1-1/+1
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-09git remote doc: correct dangerous lies about what prune doesLibravatar Ævar Arnfjörð Bjarmason1-5/+9
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" (CACi5S_39wNrbfjLfn0xhCY+uewtFN2YmnAcRc86z6pjUTjWPHQ@mail.gmail.com) by Michael Giuffrida for the initial report. Reported-by: Michael Giuffrida <michaelpg@chromium.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-5/+5
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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-29Merge branch 'xf/user-manual-markup'Libravatar Junio C Hamano1-1/+1
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 textLibravatar Junio C Hamano1-1/+1
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 <gitster@pobox.com>
2015-09-17remote: add get-url subcommandLibravatar Ben Boeckel1-0/+10
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 <mathstuf@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06Merge branch 'mg/doc-remote-tags-or-not'Libravatar Junio C Hamano1-0/+3
"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-tagsLibravatar Michael J Gruber1-0/+3
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29Documentation/git-remote.txt: stress that set-url is not for triangularLibravatar Junio C Hamano1-6/+14
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 <gitster@pobox.com>
2014-02-11docs/git-remote: capitalize first word of initial blurbLibravatar Albert L. Lash, IV1-1/+1
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 <alash3@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-27remote doc: document long forms of set-head optionsLibravatar Philip Oakley1-3/+3
"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 <philipoakley@iee.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-06-22Documentation: Update the NFS remote examples to use the staging repoLibravatar W. Trevor King1-9/+16
linux-nfs.org 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://git.linux-nfs.org/projects/bfields/linux.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 <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-17documentation: trivial style cleanupsLibravatar Felipe Contreras1-1/+1
White-spaces, missing braces, standardize --[no-]foo. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24remote: 'show' and 'prune' can take more than one remoteLibravatar Thomas Rast1-2/+2
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 <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06remote: prefer subcommand name 'remove' to 'rm'Libravatar Nguyễn Thái Ngọc Duy1-1/+2
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-3/+3
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 <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-23Merge branch 'pj/remote-set-branches-usage-fix'Libravatar Junio C Hamano1-1/+1
* pj/remote-set-branches-usage-fix: remote: fix set-branches usage and documentation Conflicts: builtin/remote.c
2012-02-19remote: fix set-branches usage and documentationLibravatar Philip Jägenstedt1-1/+1
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 <philip@foolip.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-23git-remote.txt: avoid sounding as if loose refs are the only ones in the worldLibravatar Junio C Hamano1-9/+10
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 <gitster@pobox.com>
2011-06-23git-remote.txt: fix wrong remote refspecLibravatar Namhyung Kim1-6/+6
$GIT_DIR/remotes/<name>/<branch> should be $GIT_DIR/refs/remotes/<name>/<branch>. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06Merge branch 'jk/maint-remote-mirror-safer'Libravatar Junio C Hamano1-6/+9
* 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 --mirrorLibravatar Jeff King1-4/+0
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30remote: separate the concept of push and fetch mirrorsLibravatar Jeff King1-6/+13
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-10/+0
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"Libravatar Matthieu Moy1-1/+1
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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Replace "remote tracking" with "remote-tracking"Libravatar Matthieu Moy1-2/+2
"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. http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com 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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-08Use parentheses and `...' where appropriateLibravatar Štěpán Němec1-1/+1
Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-08Use angles for placeholders consistentlyLibravatar Štěpán Němec1-1/+1
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-18Merge branch 'jn/remote-set-branches'Libravatar Junio C Hamano1-0/+13
* jn/remote-set-branches: Add git remote set-branches Conflicts: builtin/remote.c
2010-05-19Add git remote set-branchesLibravatar Jonathan Nieder1-0/+13
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 <madduck@debian.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-19remote add: add a --[no-]tags optionLibravatar Samuel Tardieu1-1/+7
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 <sam@rfc1149.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-22Merge branch 'il/remote-updates'Libravatar Junio C Hamano1-0/+17
* il/remote-updates: Add git remote set-url
2010-01-18Add git remote set-urlLibravatar Ilari Liusvaara1-0/+17
Add 'git remote set-url' for changing URL of remote repository with one "porcelain-level" command. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-1/+1
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-20git remote: Separate usage strings for subcommandsLibravatar Tim Henigan1-3/+4
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 <tim.henigan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10Fix typos in git-remote.txt and git-symbolic-ref.txtLibravatar Štěpán Němec1-2/+2
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07git remote update: Fallback to remote if group does not existLibravatar Finn Arne Gangstad1-1/+1
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 <finnag@pvv.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-05git remote update: New option --pruneLibravatar Finn Arne Gangstad1-1/+3
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 <finnag@pvv.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27builtin-remote: add set-head subcommandLibravatar Jay Soffian1-2/+26
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 <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11git-remote: document the migration feature of the rename subcommandLibravatar Miklos Vajna1-0/+4
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-05Implement git remote renameLibravatar Miklos Vajna1-0/+6
The new rename subcommand does the followings: 1) Renames the remote.foo configuration section to remote.bar 2) Updates the remote.bar.fetch 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 <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize command names in synopsesLibravatar Jonathan Nieder1-5/+5
To tell command names from options in a glance. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>