summaryrefslogtreecommitdiff
path: root/t/t5505-remote.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-09Merge branch 'ab/git-remote-exit-code'Libravatar Junio C Hamano1-8/+8
Exit codes from "git remote add" etc. were not usable by scripted callers. * ab/git-remote-exit-code: remote: add meaningful exit code on missing/existing
2020-11-02Merge branch 'js/default-branch-name-part-4-minus-1'Libravatar Junio C Hamano1-15/+15
Adjust tests so that they won't scream when the default initial branch name is changed to 'main'. * js/default-branch-name-part-4-minus-1: t1400: prepare for `main` being default branch name tests: prepare aligned mentions of the default branch name t9902: prepare a test for the upcoming default branch name t3200: prepare for `main` being shorter than `master` t5703: adjust a test case for the upcoming default branch name t6200: adjust suppression pattern to also match "main" tests: start moving to a different default main branch name t9801: use `--` in preparation for default branch rename fmt-merge-msg: also suppress "into main" by default
2020-10-27remote: add meaningful exit code on missing/existingLibravatar Ævar Arnfjörð Bjarmason1-8/+8
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-23tests: prepare aligned mentions of the default branch nameLibravatar Johannes Schindelin1-15/+15
In some tests, the default branch name is part of aligned output. As we want to change the default branch name to `main`, which is two characters shorter than the old default branch name, we will have to adjust those tests. Since we use the original default branch name until the entire test suite has been adjusted accordingly, the touched test cases need to be guarded by a prereq (that is so far disabled so that they are skipped for now). The test cases that depend on those test cases that are newly guarded by that prereq naturally have to be guarded, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30remote: add tests for add and rename with invalid namesLibravatar Sean Barag1-0/+13
In preparation for a future patch that moves `builtin/remote.c`'s remote-name validation, ensure `git remote add` and `git remote rename` report errors when the new name isn't valid. Signed-off-by: Sean Barag <sean@barag.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-25tests: reference `seen` wherever `pu` was referencedLibravatar Johannes Schindelin1-4/+4
As our test suite partially reflects how we work in the Git project, it is natural that the branch name `pu` was used in a couple places. Since that branch was renamed to `seen`, let's use the new name consistently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-10remote rename/remove: gently handle remote.pushDefault configLibravatar Bert Wesarg1-2/+74
When renaming a remote with git remote rename X Y git remote remove X Git already renames or removes any branch.<name>.remote and branch.<name>.pushRemote configurations if their value is X. However remote.pushDefault needs a more gentle approach, as this may be set in a non-repo configuration file. In such a case only a warning is printed, such as: warning: The global configuration remote.pushDefault in: $HOME/.gitconfig:35 now names the non-existent remote origin It is changed to remote.pushDefault = Y or removed when set in a repo configuration though. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-10remote rename/remove: handle branch.<name>.pushRemote config valuesLibravatar Bert Wesarg1-1/+15
When renaming or removing a remote with git remote rename X Y git remote remove X Git already renames/removes any config values from branch.<name>.remote = X to branch.<name>.remote = Y As branch.<name>.pushRemote also names a remote, it now also renames or removes these config values from branch.<name>.pushRemote = X to branch.<name>.pushRemote = Y Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14push: test that <src> doesn't DWYM if <dst> is unqualifiedLibravatar Ævar Arnfjörð Bjarmason1-0/+27
Add a test asserting that "git push origin <src>:<dst>" where <src> is a branch, tag, tree or blob in refs/remotes/* doesn't DWYM when <dst> is unqualified. This has never been the case, but there haven't been any tests for this behavior. See f88395ac23 ("Renaming push.", 2005-08-03), bb9fca80ce ("git-push: Update description of refspecs and add examples", 2007-06-09) and f8aae12034 ("push: allow unqualified dest refspecs to DWIM", 2008-04-23) which are most relevant commits that have changed or documented the behavior of the DWYM feature in the past. These tests were originally meant to lead up to a patch that made refs/remotes/* on the LHS imply refs/heads/* on the RHS, see [1]. That patch proved controversial and may not ever land in git.git, but we should have the tests that remind us what the current behavior is in case it's ever changed. 1. https://public-inbox.org/git/20181026230741.23321-8-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14push: add an advice on unqualified <dst> pushLibravatar Ævar Arnfjörð Bjarmason1-0/+28
Add an advice to the recently improved error message added in f8aae12034 ("push: allow unqualified dest refspecs to DWIM", 2008-04-23). Now with advice.pushUnqualifiedRefName=true (on by default) we show a hint about how to proceed: $ ./git-push avar v2.19.0^{commit}:newbranch -n error: The destination you provided is not a full refname (i.e., starting with "refs/"). We tried to guess what you meant by: - Looking for a ref that matches 'newbranch' on the remote side. - Checking if the <src> being pushed ('v2.19.0^{commit}') is a ref in "refs/{heads,tags}/". If so we add a corresponding refs/{heads,tags}/ prefix on the remote side. Neither worked, so we gave up. You must fully qualify the ref. hint: The <src> part of the refspec is a commit object. hint: Did you mean to create a new branch by pushing to hint: 'v2.19.0^{commit}:refs/heads/newbranch'? error: failed to push some refs to 'git@github.com:avar/git.git' When trying to push a tag, tree or a blob we suggest that perhaps the user meant to push them to refs/tags/ instead. The if/else duplication for all of OBJ_{COMMIT,TAG,TREE,BLOB} is unfortunate, but is required to correctly mark the messages for translation. See the discussion in <87r2gxebsi.fsf@evledraar.gmail.com> about that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-14builtin/remote: quote remote name on error to display empty nameLibravatar Shulhan1-2/+2
When adding new remote name with empty string, git will print the following error message, fatal: '' is not a valid remote name\n But when removing remote name with empty string as input, git shows the empty string without quote, fatal: No such remote: \n To make these error messages consistent, quote the name of the remote that we tried and failed to find. Signed-off-by: Shulhan <m.shulhan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-4/+2
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-08-15Merge branch 'nd/i18n'Libravatar Junio C Hamano1-1/+1
Many more strings are prepared for l10n. * nd/i18n: (23 commits) transport-helper.c: mark more strings for translation transport.c: mark more strings for translation sha1-file.c: mark more strings for translation sequencer.c: mark more strings for translation replace-object.c: mark more strings for translation refspec.c: mark more strings for translation refs.c: mark more strings for translation pkt-line.c: mark more strings for translation object.c: mark more strings for translation exec-cmd.c: mark more strings for translation environment.c: mark more strings for translation dir.c: mark more strings for translation convert.c: mark more strings for translation connect.c: mark more strings for translation config.c: mark more strings for translation commit-graph.c: mark more strings for translation builtin/replace.c: mark more strings for translation builtin/pack-objects.c: mark more strings for translation builtin/grep.c: mark strings for translation builtin/config.c: mark more strings for translation ...
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-4/+2
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23refs.c: mark more strings for translationLibravatar Nguyễn Thái Ngọc Duy1-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-07-16t5000-t5999: fix broken &&-chainsLibravatar Eric Sunshine1-1/+1
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t5505: modernize and simplify hard-to-digest testLibravatar Eric Sunshine1-6/+2
This test uses a subshell within a subshell but is formatted in such a way as to suggests that the inner subshell is a sibling rather than a child, which makes it difficult to digest the test's structure and intent. Worse, the inner subshell performs cleanup of actions from earlier in the test, however, a failure between the initial actions and the cleanup will prevent the cleanup from taking place. Fix these problems by modernizing and simplifying the test and by using test_when_finished() for the cleanup action. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'rl/remote-allow-missing-branch-name-merge'Libravatar Junio C Hamano1-0/+19
"git remote rm X", when a branch has remote X configured as the value of its branch.*.remote, tried to remove branch.*.remote and branch.*.merge and failed if either is unset. * rl/remote-allow-missing-branch-name-merge: remote: ignore failure to remove missing branch.<name>.merge
2017-02-27Merge branch 'mh/ref-remove-empty-directory'Libravatar Junio C Hamano1-1/+1
Deletion of a branch "foo/bar" could remove .git/refs/heads/foo once there no longer is any other branch whose name begins with "foo/", but we didn't do so so far. Now we do. * mh/ref-remove-empty-directory: (23 commits) files_transaction_commit(): clean up empty directories try_remove_empty_parents(): teach to remove parents of reflogs, too try_remove_empty_parents(): don't trash argument contents try_remove_empty_parents(): rename parameter "name" -> "refname" delete_ref_loose(): inline function delete_ref_loose(): derive loose reference path from lock log_ref_write_1(): inline function log_ref_setup(): manage the name of the reflog file internally log_ref_write_1(): don't depend on logfile argument log_ref_setup(): pass the open file descriptor back to the caller log_ref_setup(): improve robustness against races log_ref_setup(): separate code for create vs non-create log_ref_write(): inline function rename_tmp_log(): improve error reporting rename_tmp_log(): use raceproof_create_file() lock_ref_sha1_basic(): use raceproof_create_file() lock_ref_sha1_basic(): inline constant raceproof_create_file(): new function safe_create_leading_directories(): set errno on SCLD_EXISTS safe_create_leading_directories_const(): preserve errno ...
2017-02-21remote: ignore failure to remove missing branch.<name>.mergeLibravatar Ross Lagerwall1-0/+19
It is not all too unusual for a branch to use "branch.<name>.remote" without "branch.<name>.merge". You may be using the 'push.default' configuration set to 'current', for example, and do $ git checkout -b side colleague/side $ git config branch.side.remote colleague However, "git remote rm" to remove the remote used in such a manner fails with "fatal: could not unset 'branch.<name>.merge'" because it assumes that a branch that has .remote defined must also have .merge defined. Detect the "cannot unset because it is not set to begin with" case and ignore it. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19remote rename: more carefully determine whether a remote is configuredLibravatar Johannes Schindelin1-1/+1
One of the really nice features of the ~/.gitconfig file is that users can override defaults by their own preferred settings for all of their repositories. One such default that some users like to override is whether the "origin" remote gets auto-pruned or not. The user would simply call git config --global remote.origin.prune true and from now on all "origin" remotes would be pruned automatically when fetching into the local repository. There is just one catch: now Git thinks that the "origin" remote is configured, even if the repository config has no [remote "origin"] section at all, as it does not realize that the "prune" setting was configured globally and that there really is no "origin" remote configured in this repository. That is a problem e.g. when renaming a remote to a new name, when Git may be fooled into thinking that there is already a remote of that new name. Let's fix this by paying more attention to *where* the remote settings came from: if they are configured in the local repository config, we must not overwrite them. If they were configured elsewhere, we cannot overwrite them to begin with, as we only write the repository config. There is only one caller of remote_is_configured() (in `git fetch`) that may want to take remotes into account even if they were configured outside the repository config; all other callers essentially try to prevent the Git command from overwriting settings in the repository config. To accommodate that fact, the remote_is_configured() function now requires a parameter that states whether the caller is interested in all remotes, or only in those that were configured in the repository config. Many thanks to Jeff King whose tireless review helped with settling for nothing less than the current strategy. This fixes https://github.com/git-for-windows/git/issues/888 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19remote rename: demonstrate a bogus "remote exists" bugLibravatar Johannes Schindelin1-0/+7
Some users like to set `remote.origin.prune = true` in their ~/.gitconfig so that all of their repositories use that default. However, our code is ill-prepared for this, mistaking that single entry to mean that there is already a remote of the name "origin", even if there is not. This patch adds a test case demonstrating this issue. Reported by Andrew Arnott. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07t5505: use "for-each-ref" to test for the non-existence of referencesLibravatar Michael Haggerty1-1/+1
Instead of looking on the filesystem inside ".git/refs/remotes/origin", use "git for-each-ref" to check for leftover references under the remote's old name. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17tests: use test_i18n* functions to suppress false positivesLibravatar Vasco Almeida1-1/+1
The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from plumbing, the test would fail, and the string should be unmarked, since it is not seen by users. Thus, it is productive to not have false positives when running the test under GETTEXT_POISON. This commit replaces normal test functions by their i18n aware variants in use-cases know to be correctly marked for translation, suppressing false positives. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-26Merge branch 'ps/config-error'Libravatar Junio C Hamano1-0/+9
Many codepaths forget to check return value from git_config_set(); the function is made to die() to make sure we do not proceed when setting a configuration variable failed. * ps/config-error: config: rename git_config_set_or_die to git_config_set config: rename git_config_set to git_config_set_gently compat: die when unable to set core.precomposeunicode sequencer: die on config error when saving replay opts init-db: die on config errors when initializing empty repo clone: die on config error in cmd_clone remote: die on config error when manipulating remotes remote: die on config error when setting/adding branches remote: die on config error when setting URL submodule--helper: die on config error when cloning module submodule: die on config error when linking modules branch: die on config error when editing branch description branch: die on config error when unsetting upstream branch: report errors in tracking branch setup config: introduce set_or_die wrappers
2016-02-26Merge branch 'tg/git-remote'Libravatar Junio C Hamano1-0/+33
The internal API to interact with "remote.*" configuration variables has been streamlined. * tg/git-remote: remote: use remote_is_configured() for add and rename remote: actually check if remote exits remote: simplify remote_is_configured() remote: use parse_config_key
2016-02-22Merge branch 'js/git-remote-add-url-insteadof-test'Libravatar Junio C Hamano1-0/+5
* js/git-remote-add-url-insteadof-test: t5505: 'remote add x y' should work when url.y.insteadOf = x
2016-02-22remote: die on config error when setting URLLibravatar Patrick Steinhardt1-0/+9
When invoking `git-remote --set-url` we do not check the return value when writing the actual new URL to the configuration file, pretending to the user that the configuration has been set while it was in fact not persisted. Fix this problem by dying early when setting the config fails. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17t5505: 'remote add x y' should work when url.y.insteadOf = xLibravatar Johannes Schindelin1-0/+5
This is the test missing from fb86e32 (git remote: allow adding remotes agreeing with url.<...>.insteadOf, 2014-12-23): we should allow adding a remote with the URL when it agrees with the url.<...>.insteadOf setting. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16remote: use remote_is_configured() for add and renameLibravatar Thomas Gummerer1-0/+15
Both remote add and remote rename use a slightly different hand-rolled check if the remote exits. The hand-rolled check may have some subtle cases in which it might fail to detect when a remote already exists. One such case was fixed in fb86e32 ("git remote: allow adding remotes agreeing with url.<...>.insteadOf"). Another case is when a remote is configured as follows: [remote "foo"] vcs = bar If we try to run `git remote add foo bar` with the above remote configuration, git segfaults. This change fixes it. In addition, git remote rename $existing foo with the configuration for foo as above silently succeeds, even though foo already exists, modifying its configuration. With this patch it fails with "remote foo already exists". Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16remote: actually check if remote exitsLibravatar Thomas Gummerer1-0/+18
When converting the git remote command to a builtin in 211c89 ("Make git-remote a builtin"), a few calls to check if a remote exists were converted from: if (!exists $remote->{$name}) { [...] to: remote = remote_get(argv[1]); if (!remote) [...] The new check is not quite correct, because remote_get() never returns NULL if a name is given. This leaves us with the somewhat cryptic error message "error: Could not remove config section 'remote.test'", if we are trying to remove a remote that does not exist, or a similar error if we try to rename a remote. Use the remote_is_configured() function to check whether the remote actually exists, and die with a more sensible error message ("No such remote: $remotename") instead if it doesn't. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28t/t5505-remote.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-1/+1
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17remote: add get-url subcommandLibravatar Ben Boeckel1-0/+37
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-25t: fix some trivial cases of ignored exit codes in loopsLibravatar Jeff King1-4/+4
These are all cases where we do a setup step of the form: for i in $foo; do set_up $i || break done && more_setup would not notice a failure in set_up (because break always returns a 0 exit code). These are just setup steps that we do not expect to fail, but it does not hurt to be defensive. Most can be fixed by converting the "break" to a "return 1" (since we eval our tests inside a function for just this purpose). A few of the loops are inside subshells, so we can use just "exit 1" to break out of the subshell. And a few can actually be made shorter by just unrolling the loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-23Add a regression test for 'git remote add <existing> <same-url>'Libravatar Johannes Schindelin1-0/+5
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17connect: annotate refs with their symref information in get_remote_head()Libravatar Junio C Hamano1-11/+4
By doing this, clients of upload-pack can now reliably tell what ref a symbolic ref points at; the updated test in t5505 used to expect failure due to the ambiguity and made sure we give diagnostics, but we no longer need to be so pessimistic. Make sure we correctly learn which branch HEAD points at from the other side instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17t5505: fix "set-head --auto with ambiguous HEAD" testLibravatar Junio C Hamano1-0/+1
When two or more branches point at the same commit and HEAD is pointing at one of them, without the symref extension, there is no way to remotely tell which one of these branches HEAD points at. The test in question attempts to make sure that this situation is diagnosed and results in a failure. However, even if there _were_ a way to reliably tell which branch the HEAD points at, "set-head --auto" would fail if there is no remote tracking branch. Make sure that this test does not fail for that "wrong" reason. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12Merge branch 'ms/remote-tracking-branches-in-doc'Libravatar Junio C Hamano1-1/+1
* ms/remote-tracking-branches-in-doc: Change "remote tracking" to "remote-tracking"
2013-07-03Change "remote tracking" to "remote-tracking"Libravatar Michael Schubert1-1/+1
Fix a typo ("remote remote-tracking") going back to the big cleanup in 2010 (8b3f3f84 etc). Also, remove some more occurrences of "tracking" and "remote tracking" in favor of "remote-tracking". Signed-off-by: Michael Schubert <mschub@elegosoft.com> Reviewed-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23t/t5505-remote: test multiple push/pull in remotes-fileLibravatar Ramkumar Ramachandra1-2/+14
Extend the test "migrate a remote from named file in $GIT_DIR/remotes" to test that multiple "Push:" and "Pull:" lines in the remotes-file works as expected. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23t/t5505-remote: test url-with-# in branches-fileLibravatar Ramkumar Ramachandra1-4/+18
Add one more test similar to "migrate a remote from named file in $GIT_DIR/branches" to check that a url with a # can be used to specify the branch name (as opposed to the constant "master"). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23t/t5505-remote: use test_path_is_missingLibravatar Ramkumar Ramachandra1-2/+2
Replace instances of ! test -f with test_path_is_missing. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23t/t5505-remote: test push-refspec in branches-fileLibravatar Ramkumar Ramachandra1-1/+2
The test "migrate a remote from named file in $GIT_DIR/branches" reads the branches-file, but only checks that the url and fetch-refspec are set correctly. Check that the push-refspec is also set correctly. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23t/t5505-remote: modernize styleLibravatar Ramkumar Ramachandra1-373/+440
Modernize the style of all tests throughout the file: - Remove spurious blank lines. - Indent the test body. - Make sure that all lines end with &&, to make it easier to spot breaks in the chain. - When executing something in a subshell, put the parenthesis on separate lines and indent the body. Also make sure that the first statement in the subshell is a 'cd'. - When redirecting input or output, do not use SP between redirection operator and the target filename. - Use the <<-\EOF and <<-EOF forms of heredoc, not <<EOF, when the command is indented and the heredoc text itself does not have to have a leading tab. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01Merge branch 'tr/remote-tighten-commandline-parsing'Libravatar Junio C Hamano1-0/+22
* tr/remote-tighten-commandline-parsing: remote: 'show' and 'prune' can take more than one remote remote: check for superfluous arguments in 'git remote add' remote: add a test for extra arguments, according to docs
2013-04-24remote: 'show' and 'prune' can take more than one remoteLibravatar Thomas Rast1-8/+3
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>
2013-04-24remote: check for superfluous arguments in 'git remote add'Libravatar Thomas Rast1-1/+1
The 'git remote add' subcommand did not check for superfluous command line arguments. Make it so. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24remote: add a test for extra arguments, according to docsLibravatar Thomas Rast1-0/+27
This adds one test or comment for each subcommand of git-remote according to its current documentation. All but 'set-branches' and 'update' are listed as taking only a fixed number of arguments; for those we can write a test with one more (bogus) argument, and see if the command notices that. They fail on several counts: 'add' does not check for extra arguments, and 'show' and 'prune' actually iterate over remotes (i.e., take any number of args). We'll fix them in the next two patches. The -f machinery is only there to make the tests readable while still ensuring they pass as a whole, and will be removed in the final patch. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04t5505: do not assume the "matching" push is the defaultLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-12Merge branch 'nd/maint-remote-remove'Libravatar Junio C Hamano1-2/+2
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'