aboutsummaryrefslogtreecommitdiff
path: root/t/t5505-remote.sh
Commit message (Collapse)AuthorAge
* Merge branch 'ps/config-error'Junio C Hamano2016-02-26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * remote: die on config error when setting URLPatrick Steinhardt2016-02-22
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'tg/git-remote'Junio C Hamano2016-02-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | remote: use remote_is_configured() for add and renameThomas Gummerer2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | remote: actually check if remote exitsThomas Gummerer2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'js/git-remote-add-url-insteadof-test'Junio C Hamano2016-02-22
|\ \ \ | |/ / |/| | | | | | | | * js/git-remote-add-url-insteadof-test: t5505: 'remote add x y' should work when url.y.insteadOf = x
| * | t5505: 'remote add x y' should work when url.y.insteadOf = xJohannes Schindelin2016-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | t/t5505-remote.sh: use the $( ... ) construct for command substitutionElia Pinto2015-12-28
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | remote: add get-url subcommandBen Boeckel2015-09-17
| | | | | | | | | | | | | | | | | | 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>
* | t: fix some trivial cases of ignored exit codes in loopsJeff King2015-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Add a regression test for 'git remote add <existing> <same-url>'Johannes Schindelin2014-12-23
|/ | | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* connect: annotate refs with their symref information in get_remote_head()Junio C Hamano2013-09-17
| | | | | | | | | | 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>
* t5505: fix "set-head --auto with ambiguous HEAD" testJunio C Hamano2013-09-17
| | | | | | | | | | | | | | | 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>
* Merge branch 'ms/remote-tracking-branches-in-doc'Junio C Hamano2013-07-12
|\ | | | | | | | | * ms/remote-tracking-branches-in-doc: Change "remote tracking" to "remote-tracking"
| * Change "remote tracking" to "remote-tracking"Michael Schubert2013-07-03
| | | | | | | | | | | | | | | | | | | | 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>
* | t/t5505-remote: test multiple push/pull in remotes-fileRamkumar Ramachandra2013-06-23
| | | | | | | | | | | | | | | | | | 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>
* | t/t5505-remote: test url-with-# in branches-fileRamkumar Ramachandra2013-06-23
| | | | | | | | | | | | | | | | | | 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>
* | t/t5505-remote: use test_path_is_missingRamkumar Ramachandra2013-06-23
| | | | | | | | | | | | | | 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>
* | t/t5505-remote: test push-refspec in branches-fileRamkumar Ramachandra2013-06-23
| | | | | | | | | | | | | | | | | | 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>
* | t/t5505-remote: modernize styleRamkumar Ramachandra2013-06-23
|/ | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'tr/remote-tighten-commandline-parsing'Junio C Hamano2013-05-01
|\ | | | | | | | | | | | | * 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
| * remote: 'show' and 'prune' can take more than one remoteThomas Rast2013-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * remote: check for superfluous arguments in 'git remote add'Thomas Rast2013-04-24
| | | | | | | | | | | | | | | | 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>
| * remote: add a test for extra arguments, according to docsThomas Rast2013-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | t5505: do not assume the "matching" push is the defaultJunio C Hamano2013-01-04
|/ | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'nd/maint-remote-remove'Junio C Hamano2012-09-12
|\ | | | | | | | | * nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
| * remote: prefer subcommand name 'remove' to 'rm'Nguyễn Thái Ngọc Duy2012-09-06
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix tests under GETTEXT_POISON on git-remoteJiang Xin2012-08-27
|/ | | | | | | | | | | | | Use the i18n-specific test functions in test scripts for git-remote. This issue was was introduced in v1.7.10-233-gbb16d5: bb16d5 i18n: remote: mark strings for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* remote: only update remote-tracking branch if updating refspecMartin von Zweigbergk2011-09-11
| | | | | | | | | | | | | | | | | | '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>
* remote: "rename o foo" should not rename ref "origin/bar"Martin von Zweigbergk2011-09-11
| | | | | | | | | | | | | | 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>
* remote: write correct fetch spec when renaming remote 'remote'Martin von Zweigbergk2011-09-11
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* remote: allow "-t" with fetch mirrorsJeff King2011-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* remote: separate the concept of push and fetch mirrorsJeff King2011-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Change incorrect "remote branch" to "remote tracking branch" in C codeMatthieu Moy2010-11-03
| | | | | | | | | | | | | | | (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>
* Merge branch 'xx/trivial' into maintJunio C Hamano2010-09-06
|\ | | | | | | | | | | | | * xx/trivial: tag.c: whitespace breakages fix Fix whitespace issue in object.c t5505: add missing &&
| * t5505: add missing &&Jens Lehmann2010-09-05
| | | | | | | | | | Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'bg/maint-remote-update-default' into maintJunio C Hamano2010-01-20
| |\ | | | | | | | | | | | | * bg/maint-remote-update-default: Fix "git remote update" with remotes.defalt set
* | \ Merge branch 'jn/remote-set-branches'Junio C Hamano2010-06-18
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jn/remote-set-branches: Add git remote set-branches Conflicts: builtin/remote.c
| * | | Add git remote set-branchesJonathan Nieder2010-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | remote add: add a --[no-]tags optionSamuel Tardieu2010-04-19
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'bc/t5505-fix'Junio C Hamano2010-04-03
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * bc/t5505-fix: t/t5505-remote.sh: escape * to prevent interpretation by shell as glob t5505: add missing && t5505: remove unnecessary subshell invocations
| * | | t/t5505-remote.sh: escape * to prevent interpretation by shell as globBrandon Casey2010-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | t5505: add missing &&Brandon Casey2010-03-20
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | t5505: remove unnecessary subshell invocationsBrandon Casey2010-03-20
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/maint-refs-dangling'Junio C Hamano2010-03-24
|\ \ \ \ | |/ / / |/| | | | | | | | | | | * jc/maint-refs-dangling: refs: ref entry with NULL sha1 is can be a dangling symref
| * | | refs: ref entry with NULL sha1 is can be a dangling symrefJunio C Hamano2010-03-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Add git remote set-urlIlari Liusvaara2010-01-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Merge branch 'bg/maint-remote-update-default'Junio C Hamano2010-01-10
|\ \ \ \ | |_|/ / |/| | / | | |/ | |/| * bg/maint-remote-update-default: Fix "git remote update" with remotes.defalt set
| * | Fix "git remote update" with remotes.defalt setBjörn Gustavsson2009-12-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'bg/fetch-multi'Junio C Hamano2009-11-23
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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'
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-18 00:33:08 +0000