summaryrefslogtreecommitdiff
path: root/t/t5505-remote.sh
AgeCommit message (Collapse)AuthorFilesLines
2011-09-11remote: only update remote-tracking branch if updating refspecLibravatar Martin von Zweigbergk1-1/+2
'git remote rename' will only update the remote's fetch refspec if it looks like a default one. If the remote has no default fetch refspec, as in [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/remotes/upstream/* we would not update the fetch refspec and even if there is a ref called "refs/remotes/origin/master", we should not rename it, since it was not created by fetching from the remote. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11remote: "rename o foo" should not rename ref "origin/bar"Libravatar Martin von Zweigbergk1-0/+10
When renaming a remote called 'o' using 'git remote rename o foo', git should also rename any remote-tracking branches for the remote. This does happen, but any remote-tracking branches starting with 'refs/remotes/o', such as 'refs/remotes/origin/bar', will also be renamed (to 'refs/remotes/foorigin/bar' in this case). Fix it by simply matching one more character, up to the slash following the remote name. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11remote: write correct fetch spec when renaming remote 'remote'Libravatar Martin von Zweigbergk1-0/+20
When renaming a remote whose name is contained in a configured fetch refspec for that remote, we currently replace the first occurrence of the remote name in the refspec. This is correct in most cases, but breaks if the remote name occurs in the fetch refspec before the expected place. For example, we currently change [remote "remote"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/remotes/remote/* into [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/origins/remote/* Reduce the risk of changing incorrect sections of the refspec by matching the entire ":refs/remotes/<name>/" instead of just "<name>". Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26remote: allow "-t" with fetch mirrorsLibravatar Jeff King1-0/+22
Commit 13fc2c1 (remote: disallow some nonsensical option combinations, 2011-03-30) made it impossible to use "remote add -t foo --mirror". The argument was that specifying specific branches is useless because: 1. Push mirrors do not want a refspec at all. 2. The point of fetch mirroring is to use a broad refspec like "refs/*", but using "-t" overrides that. Point (1) is valid; "-t" with push mirrors is useless. But point (2) ignored another side effect of using --mirror: it fetches the refs directly into the refs/ namespace as they are found upstream, instead of placing them in a separate-remote layout. So 13fc2c1 was overly constrictive, and disallowed reasonable specific-branch mirroring, like: git remote add -t heads/foo -t heads/bar --mirror=fetch which makes the local "foo" and "bar" branches direct mirrors of the remote, but does not fetch anything else. This patch restores the original behavior, but only for fetch mirrors. 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-0/+78
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>
2010-11-03Change incorrect "remote branch" to "remote tracking branch" in C codeLibravatar Matthieu Moy1-3/+5
(Just like we did for documentation already) In the process, we change "non-remote branch" to "branch outside the refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch". The new formulation actually corresponds to how the code detects this case (i.e. prefixcmp(refname, "refs/remotes")). Also, we use 'remote-tracking branch' in generated merge messages (by merge an fmt-merge-msg). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06Merge branch 'xx/trivial' into maintLibravatar Junio C Hamano1-1/+1
* xx/trivial: tag.c: whitespace breakages fix Fix whitespace issue in object.c t5505: add missing &&
2010-09-05t5505: add missing &&Libravatar Jens Lehmann1-1/+1
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-18Merge branch 'jn/remote-set-branches'Libravatar Junio C Hamano1-0/+88
* jn/remote-set-branches: Add git remote set-branches Conflicts: builtin/remote.c
2010-05-19Add git remote set-branchesLibravatar Jonathan Nieder1-0/+88
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-0/+63
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-04-03Merge branch 'bc/t5505-fix'Libravatar Junio C Hamano1-41/+6
* bc/t5505-fix: t/t5505-remote.sh: escape * to prevent interpretation by shell as glob t5505: add missing && t5505: remove unnecessary subshell invocations
2010-03-24Merge branch 'jc/maint-refs-dangling'Libravatar Junio C Hamano1-3/+3
* jc/maint-refs-dangling: refs: ref entry with NULL sha1 is can be a dangling symref
2010-03-20t/t5505-remote.sh: escape * to prevent interpretation by shell as globLibravatar Brandon Casey1-1/+1
This test is supposed to check that git-remote correctly refuses to delete all URLS for the specified remote which match the '.*' regular expression. Since the '*' was not protected, it was interpreted by the shell as a file glob and expanded before being passed to git-remote. The call to git-remote still exited non-zero in this case, and the overall test still passed, but it exited non-zero because git-remote was passed the incorrect number of arguments, not for the reason it was supposed to fail. Correct the test by escaping the '*'. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20t5505: add missing &&Libravatar Brandon Casey1-1/+1
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20t5505: remove unnecessary subshell invocationsLibravatar Brandon Casey1-39/+4
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15refs: ref entry with NULL sha1 is can be a dangling symrefLibravatar Junio C Hamano1-3/+3
Brandon Casey noticed that t5505 had accidentally broken its && chain, hiding inconsistency between the code that writes the warning to the standard output and the test that expects to see the warning on the standard error, which was introduced by f8948e2 (remote prune: warn dangling symrefs, 2009-02-08). It turns out that the issue is deeper than that. After f8948e2, a symref that is dangling is marked with a NULL sha1, and the idea of using NULL sha1 to mean a deleted ref was scrapped, but somehow a follow-up eafb452 (do_one_ref(): null_sha1 check is not about broken ref, 2009-07-22) incorrectly reorganized do_one_ref(), still thinking NULL sha1 is never used in the code. Fix this by: - adopt Brandon's fix to t5505 test; - introduce REF_BROKEN flag to mark a ref that fails to resolve (dangling symref); - move the check for broken ref back inside the "if we are skipping dangling refs" code block. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'bg/maint-remote-update-default' into maintLibravatar Junio C Hamano1-0/+14
* bg/maint-remote-update-default: Fix "git remote update" with remotes.defalt set
2010-01-18Add git remote set-urlLibravatar Ilari Liusvaara1-1/+215
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-10Merge branch 'bg/maint-remote-update-default'Libravatar Junio C Hamano1-0/+14
* bg/maint-remote-update-default: Fix "git remote update" with remotes.defalt set
2009-12-31Fix "git remote update" with remotes.defalt setLibravatar Björn Gustavsson1-0/+14
Starting from commit 8db35596, "git remote update" (with no group name given) will fail with the following message if remotes.default has been set in the config file: fatal: 'default' does not appear to be a git repository fatal: The remote end hung up unexpectedly The problem is that the --multiple option is not passed to "git fetch" if no remote or group name is given on the command line. Fix the problem by always passing the --multiple option to "git fetch" (which actually simplifies the code). Reported-by: YONETANI Tomokazu Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-23Merge branch 'bg/fetch-multi'Libravatar Junio C Hamano1-0/+11
* bg/fetch-multi: Re-implement 'git remote update' using 'git fetch' builtin-fetch: add --dry-run option builtin-fetch: add --prune option teach warn_dangling_symref to take a FILE argument remote: refactor some logic into get_stale_heads() Add missing test for 'git remote update --prune' Add the configuration option skipFetchAll Teach the --multiple option to 'git fetch' Teach the --all option to 'git fetch'
2009-11-10Add missing test for 'git remote update --prune'Libravatar Björn Gustavsson1-0/+11
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-1/+1
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-13builtin-remote: Show push urls as wellLibravatar Michael J Gruber1-3/+7
Teach builtin remote to show push urls also when asked to "show" a specific remote. This improves upon the standard display mode: multiple specified "url"s mean that the first one is for fetching, all are used for pushing. We make this clearer now by displaying the first one prefixed with "Fetch URL", and all "url"s (or, if present, all "pushurl"s) prefixed with "Push URL". Example with "one" having one url, "two" two urls, "three" one url and one pushurl (URL part only): * remote one Fetch URL: hostone.com:/somepath/repoone.git Push URL: hostone.com:/somepath/repoone.git * remote two Fetch URL: hosttwo.com:/somepath/repotwo.git Push URL: hosttwo.com:/somepath/repotwo.git Push URL: hosttwobackup.com:/somewheresafe/repotwo.git * remote three Fetch URL: http://hostthree.com/otherpath/repothree.git Push URL: hostthree.com:/pathforpushes/repothree.git Also, adjust t5505 accordingly and make it test for the new output. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-27fix segfault showing an empty remoteLibravatar Clemens Buchacher1-0/+10
In case of an empty list, the search for its tail caused a NULL-pointer dereference. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Reported-by: Erik Faye-Lund <kusmabite@googlemail.com> Acked-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27builtin-remote: new show output style for push refspecsLibravatar Jay Soffian1-8/+22
The existing output of "git remote show <remote>" with respect to push ref specs is basically just to show the raw refspec. This patch teaches the command to interpret the refspecs and show how each branch will be pushed to the destination. The output gives the user an idea of what "git push" should do if it is run w/o any arguments. Example new output: 1a. Typical output with no push refspec (i.e. matching branches only) $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (up to date) next pushes to next (local out of date) 1b. Same as above, w/o querying the remote: $ git remote show origin -n * remote origin [...] Local ref configured for 'git push' (status not queried): (matching) pushes to (matching) 2a. With a forcing refspec (+), and a new topic (something like push = refs/heads/*:refs/heads/*): $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (fast forwardable) new-topic pushes to new-topic (create) next pushes to next (local out of date) pu forces to pu (up to date) 2b. Same as above, w/o querying the remote $ git remote show origin -n * remote origin [...] Local refs configured for 'git push' (status not queried): master pushes to master new-topic pushes to new-topic next pushes to next pu forces to pu 3. With a remote configured as a mirror: * remote backup [...] Local refs will be mirrored by 'git push' Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27builtin-remote: new show output styleLibravatar Jay Soffian1-17/+21
The existing output of "git remote show <remote>" is too verbose for the information it provides. This patch teaches it to provide more information in less space. The output for push refspecs is addressed in the next patch. Before the patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branch merged with 'git pull' while on branch master master Remote branch merged with 'git pull' while on branch next next Remote branches merged with 'git pull' while on branch octopus foo bar baz frotz New remote branch (next fetch will store in remotes/origin) html Stale tracking branch (use 'git remote prune') bogus Tracked remote branches maint man master next pu todo After this patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: bogus stale (use 'git remote prune' to remove) html new (next fetch will store in remotes/origin) maint tracked man tracked master tracked next tracked pu tracked todo tracked Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz $ git remote show origin -n * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: (not queried) Remote branches: (status not queried) bogus maint man master next pu todo Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27builtin-remote: add set-head subcommandLibravatar Jay Soffian1-0/+40
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>
2009-02-27builtin-remote: teach show to display remote HEADLibravatar Jay Soffian1-2/+10
This is in preparation for teaching remote how to set refs/remotes/<remote>/HEAD to match what HEAD is set to at <remote>, but is useful in its own right. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27builtin-remote: fix two inconsistencies in the output of "show <remote>"Libravatar Jay Soffian1-1/+1
Remote and stale branches are emitted in alphabetical order, but new and tracked branches are not. So sort the latter to be consistent with the former. This also lets us use more efficient string_list_has_string() instead of unsorted_string_list_has_string(). "show <remote>" prunes symrefs, but "show <remote> -n" does not. Fix the latter to match the former. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10Warn use of "origin" when remotes/origin/HEAD is danglingLibravatar Junio C Hamano1-0/+6
The previous one squelched the diagnositic message we used to issue every time we enumerated the refs and noticed a dangling ref. This adds the warning back to the place where the user actually attempts to use it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10remote prune: warn dangling symrefsLibravatar Junio C Hamano1-0/+21
If you prune from the remote "frotz" that deleted the ref your tracking branch remotes/frotz/HEAD points at, the symbolic ref will become dangling. We used to detect this as an error condition and issued a message every time refs are enumerated. This stops the error message, but moves the warning to "remote prune". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-05Merge branch 'js/maint-remote-remove-mirror'Libravatar Junio C Hamano1-0/+26
* js/maint-remote-remove-mirror: builtin-remote: make rm operation safer in mirrored repository builtin-remote: make rm() use properly named variable to hold return value
2009-02-04builtin-remote: make rm operation safer in mirrored repositoryLibravatar Jay Soffian1-0/+26
"git remote rm <repo>" happily removes non-remote refs and their reflogs. This may be okay if the repository truely is a mirror, but if the user had done "git remote add --mirror <repo>" by accident and was just undoing their mistake, then they are left in a situation that is difficult to recover from. After this commit, "git remote rm" skips over non-remote refs. The user is advised on how remove branches using "git branch -d", which itself has nice safety checks wrt to branch removal lacking from "git remote rm". Non-remote non-branch refs are skipped silently. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11git-remote rename: migrate from remotes/ and branches/Libravatar Miklos Vajna1-0/+33
Remote definition that came from $GIT_DIR/remotes/nick and $GIT_DIR/branches/nick are migrated to [remotes "nick"] section in the configuration file. 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/+15
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-10-22git-remote: list branches in vertical listsLibravatar Johannes Sixt1-5/+9
Previously, branches were listed on a single line in each section. But if there are many branches, then horizontal, line-wrapped lists are very inconvenient to scan for a human. This makes the lists vertical, i.e one branch per line is printed. Since "git remote" is porcelain, we can easily make this backwards-incompatible change. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-13Fix fetch/pull when run without --update-head-okLibravatar Johannes Schindelin1-1/+1
Some confusing tutorials suggested that it would be a good idea to fetch into the current branch with something like this: git fetch origin master:master (or even worse: the same command line with "pull" instead of "fetch"). While it might make sense to store what you want to pull, it typically is plain wrong when the current branch is "master". This should only be allowed when (an incorrect) "git pull origin master:master" tries to work around by giving --update-head-ok to underlying "git fetch", and otherwise we should refuse it, but somewhere along the lines we lost that behavior. The check for the current branch is now _only_ performed in non-bare repositories, which is an improvement from the original behaviour. Some newer tests were depending on the broken behaviour of "git fetch" this patch fixes, and have been adjusted. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-01Bring local clone's origin URL in line with that of a remote cloneLibravatar Johan Herland1-3/+3
On a local clone, "git clone" would use the fully DWIMmed path as the origin URL in the resulting repo. This was slightly inconsistent with the case of a remote clone where the _given_ URL was used as the origin URL (because the DWIMming was done remotely, and was therefore not available to "git clone"). This behaviour caused problems when cloning a local non-bare repo with relative submodule URLs, because these submodule URLs would then be resolved against the DWIMmed URL (e.g. "/repo/.git") instead of the given URL (e.g. "/repo"). This patch teaches "git clone" to use the _given_ URL - instead of the DWIMmed path - as the origin URL. This causes relative submodule URLs to be resolved correctly, as long the _given_ URL indicates the correct directory against which the submodule URLs should be resolved. The patch also updates a testcase that contained the old-style origin URLs. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-7/+7
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-10remote show: list tracked remote branches with -nLibravatar Olivier Marin1-0/+2
Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-10remote prune: print the list of pruned branchesLibravatar Olivier Marin1-0/+18
This command is really too quiet which make it unconfortable to use. Also implement a --dry-run option, in place of the original -n one, to list stale tracking branches that will be pruned, but do not actually prune them. Add a test case for --dry-run. Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-10remote show: fix the -n optionLibravatar Olivier Marin1-0/+17
The perl version accepted a -n flag, to show local informations only without querying remote heads, that seems to have been lost in the C revrite. This restores the older behaviour and add a test case. Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-31Make "git-remote prune" delete refs according to fetch specsLibravatar Shawn O. Pearce1-0/+18
A remote may be configured to fetch into tracking branches that do not match the remote name. For example a user may have created extra remotes that will fetch to the same tracking branch namespace, but from different URLs: [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = refs/heads/*:refs/remotes/origin/* [remote "alt"] url = git://repo.or.cz/alt-git.git fetch = refs/heads/*:refs/remotes/origin/* When running `git remote prune alt` we expect stale branches to be removed from "refs/remotes/origin/*" and not from the unused namespace of "refs/remotes/alt/*". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-5/+5
As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-24remote: create fetch config lines with '+'Libravatar Jeff King1-0/+10
Since git-remote always uses remote tracking branches, it should be safe to always force updates of those branches. I.e., we should generate fetch = +refs/heads/*:refs/remotes/$remote/* instead of fetch = refs/heads/*:refs/remotes/$remote/* This was the behavior of the perl version, which seems to have been lost in the C rewrite. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-18git-remote: reject adding remotes with invalid namesLibravatar Jonas Fonseca1-0/+6
This can happen if the arguments to git-remote add is switched by the user, and git would only show an error if fetching was also requested. Fix it by using the refspec parsing engine to check if the requested name can be parsed as a remote before add it. Also cleanup so that the "remote.<name>.url" config name buffer is only initialized once. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-23builtin-remote: Fix missing newline at end of listing of pushed branchesLibravatar Johannes Sixt1-0/+6
Without this the output of 'git remote show' does not end with a new-line: bash> git remote show repo * remote repo URL: repo.or.cz:/srv/git/kdbg.git Tracked remote branches maint master mob Local branch pushed with 'git push' +master:masterbash> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-19remote show: do not show symbolic refsLibravatar Johannes Schindelin1-0/+10
For symbolic refs, a sane notion of being "stale" is that the ref they point to no longer exists. Since this is checked already, "remote show" does not need to show them at all. Incidentally, this fixes the issue that "HEAD" was shown as a stale ref by "remote show" in a freshly cloned repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>