summaryrefslogtreecommitdiff
path: root/builtin/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2017-11-15Merge branch 'mh/tidy-ref-update-flags'Libravatar Junio C Hamano1-3/+3
Code clean-up in refs API implementation. * mh/tidy-ref-update-flags: refs: update some more docs to use "oid" rather than "sha1" write_packed_entry(): take `object_id` arguments refs: rename constant `REF_ISPRUNING` to `REF_IS_PRUNING` refs: rename constant `REF_NODEREF` to `REF_NO_DEREF` refs: tidy up and adjust visibility of the `ref_update` flags ref_transaction_add_update(): remove a check ref_transaction_update(): die on disallowed flags prune_ref(): call `ref_transaction_add_update()` directly files_transaction_prepare(): don't leak flags to packed transaction
2017-11-06Merge branch 'bc/object-id'Libravatar Junio C Hamano1-1/+1
Conversion from uchar[20] to struct object_id continues. * bc/object-id: (25 commits) refs/files-backend: convert static functions to object_id refs: convert read_raw_ref backends to struct object_id refs: convert peel_object to struct object_id refs: convert resolve_ref_unsafe to struct object_id worktree: convert struct worktree to object_id refs: convert resolve_gitlink_ref to struct object_id Convert remaining callers of resolve_gitlink_ref to object_id sha1_file: convert index_path and index_fd to struct object_id refs: convert reflog_expire parameter to struct object_id refs: convert read_ref_at to struct object_id refs: convert peel_ref to struct object_id builtin/pack-objects: convert to struct object_id pack-bitmap: convert traverse_bitmap_commit_list to object_id refs: convert dwim_log to struct object_id builtin/reflog: convert remaining unsigned char uses to object_id refs: convert dwim_ref and expand_ref to struct object_id refs: convert read_ref and read_ref_full to object_id refs: convert resolve_refdup and refs_resolve_refdup to struct object_id Convert check_connected to use struct object_id refs: update ref transactions to use struct object_id ...
2017-11-06refs: rename constant `REF_NODEREF` to `REF_NO_DEREF`Libravatar Michael Haggerty1-3/+3
Even after working with this code for years, I still see this constant name as "ref node ref". Rename it to make it's meaning clearer. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-21remote: handle broken symrefsLibravatar Jeff King1-1/+1
It's possible for resolve_ref_unsafe() to return NULL with a REF_ISSYMREF flag if a symref points to a broken ref. In this case, the read_remote_branches() function will segfault passing the name to xstrdup(). This is hard to trigger in practice, since this function is used as a callback to for_each_ref(), which will skip broken refs in the first place (so it would have to be broken racily, or for us to see a transient filesystem error). If we see such a racy broken outcome let's treat it as "not a symref". This is exactly the same thing that would happen in the non-racy case (our function would not be called at all, as for_each_ref would skip the broken symref). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16refs: convert read_ref and read_ref_full to object_idLibravatar brian m. carlson1-1/+1
All but two of the call sites already have parameters using the hash parameter of struct object_id, so convert them to take a pointer to the struct directly. Also convert refs_read_refs_full, the underlying implementation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-24refs: pass NULL to resolve_ref_unsafe() if hash is not neededLibravatar René Scharfe1-2/+1
This allows us to get rid of some write-only variables, among them seven SHA1 buffers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-07remote: release strbuf after use in set_url()Libravatar Rene Scharfe1-3/+3
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-07remote: release strbuf after use in migrate_file()Libravatar Rene Scharfe1-0/+1
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-07remote: release strbuf after use in read_remote_branches()Libravatar Rene Scharfe1-0/+1
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22Merge branch 'ma/parse-maybe-bool'Libravatar Junio C Hamano1-1/+1
Code clean-up. * ma/parse-maybe-bool: parse_decoration_style: drop unused argument `var` treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool config: make git_{config,parse}_maybe_bool equivalent config: introduce git_parse_maybe_bool_text t5334: document that git push --signed=1 does not work Doc/git-{push,send-pack}: correct --sign= to --signed=
2017-08-07treewide: deprecate git_config_maybe_bool, use git_parse_maybe_boolLibravatar Martin Ågren1-1/+1
The only difference between these is that the former takes an argument `name` which it ignores completely. Still, the callers are quite careful to provide reasonable values for it. Once in-flight topics have landed, we should be able to remove git_config_maybe_bool. In the meantime, document it as deprecated in the technical documentation. While at it, document git_parse_maybe_bool. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-24Merge branch 'bw/config-h'Libravatar Junio C Hamano1-0/+1
Fix configuration codepath to pay proper attention to commondir that is used in multi-worktree situation, and isolate config API into its own header file. * bw/config-h: config: don't implicitly use gitdir or commondir config: respect commondir setup: teach discover_git_directory to respect the commondir config: don't include config.h by default config: remove git_config_iter config: create config.h
2017-06-15config: don't include config.h by defaultLibravatar Brandon Williams1-0/+1
Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-05Merge branch 'mh/packed-ref-store-prep'Libravatar Junio C Hamano1-2/+2
The implementation of "ref" API around the "packed refs" have been cleaned up, in preparation for further changes. * mh/packed-ref-store-prep: (25 commits) cache_ref_iterator_begin(): avoid priming unneeded directories ref-filter: limit traversal to prefix create_ref_entry(): remove `check_name` option refs_ref_iterator_begin(): handle `GIT_REF_PARANOIA` read_packed_refs(): report unexpected fopen() failures read_packed_refs(): do more of the work of reading packed refs get_packed_ref_cache(): assume "packed-refs" won't change while locked should_pack_ref(): new function, extracted from `files_pack_refs()` ref_update_reject_duplicates(): add a sanity check ref_update_reject_duplicates(): use `size_t` rather than `int` ref_update_reject_duplicates(): expose function to whole refs module ref_transaction_prepare(): new optional step for reference updates ref_transaction_commit(): check for valid `transaction->state` files_transaction_cleanup(): new helper function files_ref_store: put the packed files lock directly in this struct files-backend: move `lock` member to `files_ref_store` lockfile: add a new method, is_lock_file_locked() ref_store: take a `msg` parameter when deleting references refs: use `size_t` indexes when iterating over ref transaction updates refs_ref_iterator_begin(): don't check prefixes redundantly ...
2017-05-31C style: use standard style for "TRANSLATORS" commentsLibravatar Ævar Arnfjörð Bjarmason1-2/+5
Change all the "TRANSLATORS: [...]" comments in the C code to use the regular Git coding style, and amend the style guide so that the example there uses that style. This custom style was necessary back in 2010 when the gettext support was initially added, and was subsequently documented in commit cbcfd4e3ea ("i18n: mention "TRANSLATORS:" marker in Documentation/CodingGuidelines", 2014-04-18). GNU xgettext hasn't had the parsing limitation that necessitated this exception for almost 3 years. Since its 0.19 release on 2014-06-02 it's been able to recognize TRANSLATOR comments in the standard Git comment syntax[1]. Usually we'd like to keep compatibility with software that's that young, but in this case literally the only person who needs to be using a gettext newer than 3 years old is Jiang Xin (the only person who runs & commits "make pot" results), so I think in this case we can make an exception. This xgettext parsing feature was added after a thread on the Git mailing list[2] which continued on the bug-gettext[3] list, but we never subsequently changed our style & styleguide, do so. There are already longstanding changes in git that use the standard comment style & have their TRANSLATORS comments extracted properly without getting the literal "*"'s mixed up in the text, as would happen before xgettext 0.19. Commit 7ff2683253 ("builtin-am: implement -i/--interactive", 2015-08-04) added one such comment, which in commit df0617bfa7 ("l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed)", 2015-09-05) got picked up in the po/git.pot file with the right format, showing that Jiang already runs a modern xgettext. The xgettext parser does not handle the sort of non-standard comment style that I'm amending here in sequencer.c, but that isn't standard Git comment syntax anyway. With this change to sequencer.c & "make pot" the comment in the pot file is now correct: #. TRANSLATORS: %s will be "revert", "cherry-pick" or -#. * "rebase -i". +#. "rebase -i". 1. http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=10af7fe6bd 2. <2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com> (https://public-inbox.org/git/2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com/) 3. https://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00016.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-23ref_store: take a `msg` parameter when deleting referencesLibravatar Michael Haggerty1-2/+2
Just because the files backend can't retain reflogs for deleted references is no reason that they shouldn't be supported by the virtual method interface. Also, `delete_ref()` and `refs_delete_ref()` have already gained `msg` parameters. Now let's add them to `delete_refs()` and `refs_delete_refs()`. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'rl/remote-allow-missing-branch-name-merge'Libravatar Junio C Hamano1-1/+3
"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-21remote: ignore failure to remove missing branch.<name>.mergeLibravatar Ross Lagerwall1-1/+3
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-02-20delete_ref: accept a reflog message argumentLibravatar Kyle Meyer1-2/+2
When the current branch is renamed with 'git branch -m/-M' or deleted with 'git update-ref -m<msg> -d', the event is recorded in HEAD's log with an empty message. In preparation for adding a more meaningful message to HEAD's log in these cases, update delete_ref() to take a message argument and pass it along to ref_transaction_delete(). Modify all callers to pass NULL for the new message argument; no change in behavior is intended. Note that this is relevant for HEAD's log but not for the deleted ref's log, which is currently deleted along with the ref. Even if it were not, an entry for the deletion wouldn't be present in the deleted ref's log. files_transaction_commit() writes to the log if REF_NEEDS_COMMIT or REF_LOG_ONLY are set, but lock_ref_for_update() doesn't set REF_NEEDS_COMMIT for the deleted ref because REF_DELETING is set. In contrast, the update for HEAD has REF_LOG_ONLY set by split_head_update(), resulting in the deletion being logged. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31Merge branch 'js/remote-rename-with-half-configured-remote'Libravatar Junio C Hamano1-7/+7
With anticipatory tweaking for remotes defined in ~/.gitconfig (e.g. "remote.origin.prune" set to true, even though there may or may not actually be "origin" remote defined in a particular Git repository), "git remote rename" and other commands misinterpreted and behaved as if such a non-existing remote actually existed. * js/remote-rename-with-half-configured-remote: remote rename: more carefully determine whether a remote is configured remote rename: demonstrate a bogus "remote exists" bug
2017-01-19remote rename: more carefully determine whether a remote is configuredLibravatar Johannes Schindelin1-7/+7
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>
2016-09-29use QSORTLibravatar René Scharfe1-2/+1
Apply the semantic patch contrib/coccinelle/qsort.cocci to the code base, replacing calls of qsort(3) with QSORT. The resulting code is shorter and supports empty arrays with NULL pointers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Merge branch 'mh/ref-iterators'Libravatar Junio C Hamano1-6/+2
The API to iterate over all the refs (i.e. for_each_ref(), etc.) has been revamped. * mh/ref-iterators: for_each_reflog(): reimplement using iterators dir_iterator: new API for iterating over a directory tree for_each_reflog(): don't abort for bad references do_for_each_ref(): reimplement using reference iteration refs: introduce an iterator interface ref_resolves_to_object(): new function entry_resolves_to_object(): rename function from ref_resolves_to_object() get_ref_cache(): only create an instance if there is a submodule remote rm: handle symbolic refs correctly delete_refs(): add a flags argument refs: use name "prefix" consistently do_for_each_ref(): move docstring to the header file refs: remove unnecessary "extern" keywords
2016-07-13Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-10/+9
More markings of messages for i18n, with updates to various tests to pass GETTEXT_POISON tests. One patch from the original submission dropped due to conflicts with jk/upload-pack-hook, which is still in flux. * va/i18n-even-more: (38 commits) t5541: become resilient to GETTEXT_POISON i18n: branch: mark comment when editing branch description for translation i18n: unmark die messages for translation i18n: submodule: escape shell variables inside eval_gettext i18n: submodule: join strings marked for translation i18n: init-db: join message pieces i18n: remote: allow translations to reorder message i18n: remote: mark URL fallback text for translation i18n: standardise messages i18n: sequencer: add period to error message i18n: merge: change command option help to lowercase i18n: merge: mark messages for translation i18n: notes: mark options for translation i18n: notes: mark strings for translation i18n: transport-helper.c: change N_() call to _() i18n: bisect: mark strings for translation t5523: use test_i18ngrep for negation t4153: fix negated test_i18ngrep call t9003: become resilient to GETTEXT_POISON tests: unpack-trees: update to use test_i18n* functions ...
2016-07-06Merge branch 'jk/string-list-static-init'Libravatar Junio C Hamano1-1/+1
Instead of taking advantage of a struct string_list that is allocated with all NULs happens to be STRING_LIST_INIT_NODUP kind, initialize them explicitly as such, to document their behaviour better. * jk/string-list-static-init: use string_list initializer consistently blame,shortlog: don't make local option variables static interpret-trailers: don't duplicate option strings parse_opt_string_list: stop allocating new strings
2016-06-20remote rm: handle symbolic refs correctlyLibravatar Michael Haggerty1-5/+1
In the modern world of reference backends, it is not OK to delete a symref by unlink()ing the file directly. This must be done via the refs API. We do so by adding the symref to the list of references to delete along with the non-symbolic references, then calling delete_refs() with the new flags option set to REF_NODEREF. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20delete_refs(): add a flags argumentLibravatar Michael Haggerty1-2/+2
This will be useful for passing REF_NODEREF through. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: remote: allow translations to reorder messageLibravatar Vasco Almeida1-4/+3
Before this patch, translations couldn't place the branch name where it was better fit in the message "and with remote <branch_name>". Allow translations that, instead of forcing the branch name to display right of the message. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: remote: mark URL fallback text for translationLibravatar Vasco Almeida1-3/+3
Marks fallback text for translation that may be displayed in git remote show output. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: builtin/remote.c: fix mark for translationLibravatar Vasco Almeida1-3/+3
The second string inside _() was not being extracted for translation by xgettext, meaning that, although the string was passed to gettext, there was no translation available. Mark each individual string instead of marking the result of ternary if. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13use string_list initializer consistentlyLibravatar Jeff King1-1/+1
There are two types of string_lists: those that own the string memory, and those that don't. You can tell the difference by the strdup_strings flag, and one should use either STRING_LIST_INIT_DUP, or STRING_LIST_INIT_NODUP as an initializer. Historically, the normal all-zeros initialization has corresponded to the NODUP case. Many sites use no initializer at all, and that works as a shorthand for that case. But for a reader of the code, it can be hard to remember which is which. Let's be more explicit and actually have each site declare which type it means to use. This is a fairly mechanical conversion; I assumed each site was correct as-is, and just switched them all to NODUP. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-09i18n: remote: add comment for translatorsLibravatar Vasco Almeida1-0/+2
Add comment drawing translator attention in order to align "Push URL:" and "Fetch URL:" fields translation of git remote show output. Aligning both fields makes the output more appealing and easier to grasp. 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-46/+24
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-22config: rename git_config_set_or_die to git_config_setLibravatar Patrick Steinhardt1-16/+16
Rename git_config_set_or_die functions to git_config_set, leading to the new default behavior of dying whenever a configuration error occurs. By now all callers that shall die on error have been transitioned to the _or_die variants, thus making this patch a simple rename of the functions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22config: rename git_config_set to git_config_set_gentlyLibravatar Patrick Steinhardt1-1/+1
The desired default behavior for `git_config_set` is to die whenever an error occurs. Dying is the default for a lot of internal functions when failures occur and is in this case the right thing to do for most callers as otherwise we might run into inconsistent repositories without noticing. As some code may rely on the actual return values for `git_config_set` we still require the ability to invoke these functions without aborting. Rename the existing `git_config_set` functions to `git_config_set_gently` to keep them available for those callers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22remote: die on config error when manipulating remotesLibravatar Patrick Steinhardt1-27/+12
When manipulating remotes we try to set various configuration values without checking if the values were persisted correctly, possibly leaving the remote in an inconsistent state. Fix this issue by dying early and notifying the user about the error. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22remote: die on config error when setting/adding branchesLibravatar Patrick Steinhardt1-17/+9
When we add or set new branches (e.g. by `git remote add -f` or `git remote set-branches`) we do not check for error codes when writing the branches to the configuration file. When persisting the configuration failed we are left with a remote that has none or not all of the branches that should have been set without notifying the user. Fix this issue by dying early on configuration error. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22remote: die on config error when setting URLLibravatar Patrick Steinhardt1-5/+6
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-16remote: use remote_is_configured() for add and renameLibravatar Thomas Gummerer1-5/+2
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-2/+2
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>
2016-02-16remote: simplify remote_is_configured()Libravatar Thomas Gummerer1-6/+6
The remote_is_configured() function allows checking whether a remote exists or not. The function however only works if remote_get() wasn't called before calling it. In addition, it only checks the configuration for remotes, but not remotes or branches files. Make use of the origin member of struct remote instead, which indicates where the remote comes from. It will be set to some value if the remote is configured in any file in the repository, but is initialized to 0 if the remote is only created in make_remote(). 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-01-13remote: handle the config setting branch.*.rebase=interactiveLibravatar Johannes Schindelin1-3/+7
The config variable branch.<branchname>.rebase is not only used by `git pull`, but also by `git remote` when showing details about a remote. Therefore, it needs to be taught to accept the newly-introduced `interactive` value of said variable. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20ref_newer: convert to use struct object_idLibravatar brian m. carlson1-1/+1
Convert ref_newer and its caller to use struct object_id instead of unsigned char *. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Convert struct ref to use object_id.Libravatar brian m. carlson1-6/+6
Use struct object_id in three fields in struct ref and convert all the necessary places that use it. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-10-05Merge branch 'bb/remote-get-url'Libravatar Junio C Hamano1-0/+59
"git remote" learned "get-url" subcommand to show the URL for a given remote name used for fetching and pushing. * bb/remote-get-url: remote: add get-url subcommand
2015-09-17remote: add get-url subcommandLibravatar Ben Boeckel1-0/+59
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-08-10remote.c: drop extraneous local variable from migrate_fileLibravatar Jeff King1-5/+2
It's an anti-pattern to assign the result of git_path to a variable, since other calls may reuse our buffer. In this case, we feed the result to unlink_or_warn immediately afterwards, so it's OK. However, it's nice to avoid assignment entirely, which makes it more obvious that there's no bug. We can just pass the result directly to unlink_or_warn, which is a known-simple function. As a bonus, the code flow is a little more obvious, as we eliminate an extra conditional (a reader does not have to wonder any more "under which circumstances is 'path' set?"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-22prune_remote(): use delete_refs()Libravatar Michael Haggerty1-9/+2
This slightly changes how errors are reported. The old and new code both report errors that come from repack_without_refs() the same way. But if an error occurs within delete_ref(), the old version only emitted an error within delete_ref() without further comment. The new version (in delete_refs()) still emits that error, but then follows it up with error(_("could not remove reference %s"), refname) The "could not remove reference" error originally came from a similar message in remove_branches() (from builtin/remote.c). This is an improvement, because the error from delete_ref() (which usually comes from ref_transaction_commit()) can be pretty low-level, like Cannot lock ref '%s': unable to resolve reference %s: %s where the last "%s" is the original strerror. In any case, I don't think we need to sweat the details too much, because these errors should only ever be seen in the case of a broken repository or a race between two processes; i.e., only in pretty rare and anomalous situations. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-22delete_refs(): new function for the refs APILibravatar Michael Haggerty1-20/+1
Move the function remove_branches() from builtin/remote.c to refs.c, rename it to delete_refs(), and make it public. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-22remove_branches(): remove temporaryLibravatar Michael Haggerty1-2/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>