summaryrefslogtreecommitdiff
path: root/remote.c
AgeCommit message (Collapse)AuthorFilesLines
2017-03-24Merge branch 'jn/remote-helpers-with-git-dir' into maintLibravatar Junio C Hamano1-1/+1
"git ls-remote" and "git archive --remote" are designed to work without being in a directory under Git's control. However, recent updates revealed that we randomly look into a directory called .git/ without actually doing necessary set-up when working in a repository. Stop doing so. * jn/remote-helpers-with-git-dir: remote helpers: avoid blind fall-back to ".git" when setting GIT_DIR remote: avoid reading $GIT_DIR config in non-repo
2017-02-14remote: avoid reading $GIT_DIR config in non-repoLibravatar Jeff King1-1/+1
The "git ls-remote" command can be run outside of a repository, but needs to look up configured remotes. The config code is smart enough to handle this case itself, but we also check the historical "branches" and "remotes" paths in $GIT_DIR. The git_path() function causes us to blindly look at ".git/remotes", even if we know we aren't in a git repository. For now, this is just an unlikely bug (you probably don't have such a file if you're not in a repository), but it will become more obvious once we merge b1ef400ee (setup_git_env: avoid blind fall-back to ".git", 2016-10-20): [now] $ git ls-remote fatal: No remote configured to list refs from. [with b1ef400ee] $ git ls-remote fatal: BUG: setup_git_env called without repository We can fix this by skipping these sources entirely when we're outside of a repository. The test is a little more complex than the demonstration above. Rather than detect the correct behavior by parsing the error message, we can actually set up a case where the remote name we give is a valid repository, but b1ef400ee would cause us to die in the configuration step. This test doesn't fail now, but it future-proofs us for the b1ef400ee change. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31Merge branch 'km/branch-get-push-while-detached' into maintLibravatar Junio C Hamano1-3/+3
"git <cmd> @{push}" on a detached HEAD used to segfault; it has been corrected to error out with a message. * km/branch-get-push-while-detached: branch_get_push: do not segfault when HEAD is detached
2017-01-31Merge branch 'js/remote-rename-with-half-configured-remote'Libravatar Junio C Hamano1-2/+10
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-2/+10
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-18Merge branch 'km/branch-get-push-while-detached'Libravatar Junio C Hamano1-3/+3
"git <cmd> @{push}" on a detached HEAD used to segfault; it has been corrected to error out with a message. * km/branch-get-push-while-detached: branch_get_push: do not segfault when HEAD is detached
2017-01-07branch_get_push: do not segfault when HEAD is detachedLibravatar Kyle Meyer1-3/+3
Move the detached HEAD check from branch_get_push_1() to branch_get_push() to avoid setting branch->push_tracking_ref when branch is NULL. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-15use strbuf_addstr() for adding constant strings to a strbuf, part 2Libravatar René Scharfe1-4/+4
Replace uses of strbuf_addf() for adding strings with more lightweight strbuf_addstr() calls. This makes the intent clearer and avoids potential issues with printf format specifiers. 02962d36845b89145cd69f8bc65e015d78ae3434 already converted six cases, this patch covers eleven more. A semantic patch for Coccinelle is included for easier checking for new cases that might be introduced in the future. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-08Merge branch 'jk/push-force-with-lease-creation' into maintLibravatar Junio C Hamano1-4/+5
"git push --force-with-lease" already had enough logic to allow ensuring that such a push results in creation of a ref (i.e. the receiving end did not have another push from sideways that would be discarded by our force-pushing), but didn't expose this possibility to the users. It does so now. * jk/push-force-with-lease-creation: t5533: make it pass on case-sensitive filesystems push: allow pushing new branches with --force-with-lease push: add shorthand for --force-with-lease branch creation Documentation/git-push: fix placeholder formatting
2016-07-26push: allow pushing new branches with --force-with-leaseLibravatar John Keeping1-4/+3
If there is no upstream information for a branch, it is likely that it is newly created and can safely be pushed under the normal fast-forward rules. Relax the --force-with-lease check so that we do not reject these branches immediately but rather attempt to push them as new branches, using the null SHA-1 as the expected value. In fact, it is already possible to push new branches using the explicit --force-with-lease=<branch>:<expect> syntax, so all we do here is make this behaviour the default if no explicit "expect" value is specified. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26push: add shorthand for --force-with-lease branch creationLibravatar John Keeping1-0/+2
Allow the empty string to stand in for the null SHA-1 when pushing a new branch, like we do when deleting branches. This means that the following command ensures that `new-branch` is created on the remote (that is, is must not already exist): git push --force-with-lease=new-branch: origin new-branch Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'nd/remote-plural-ours-plus-theirs' into maintLibravatar Junio C Hamano1-1/+1
Message fix. * nd/remote-plural-ours-plus-theirs: remote.c: specify correct plural form in "commit diverge" message
2016-05-18Merge branch 'jk/fix-attribute-macro-in-2.5' into HEADLibravatar Junio C Hamano1-1/+1
Code fixup. * jk/fix-attribute-macro-in-2.5: remote.c: spell __attribute__ correctly
2016-05-17Merge branch 'nd/remote-plural-ours-plus-theirs'Libravatar Junio C Hamano1-1/+1
Message fix. * nd/remote-plural-ours-plus-theirs: remote.c: specify correct plural form in "commit diverge" message
2016-05-06remote.c: specify correct plural form in "commit diverge" messageLibravatar Nguyễn Thái Ngọc Duy1-1/+1
We need to count both "ours" and "theirs" commits when selecting plural form for this message. Note that even though in this block, both ours and theirs must be positive (i.e. can't be in singular form), we still keep Q_(singular, plural) because languages other than English may have more than one plural form. Reported-by: Alfonsogonzalez, Ernesto (GE Digital) <ernesto.alfonsogonzalez@ge.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-03Merge branch 'jk/fix-attribute-macro-in-2.5'Libravatar Junio C Hamano1-1/+1
Code fixup. * jk/fix-attribute-macro-in-2.5: remote.c: spell __attribute__ correctly
2016-04-25remote.c: spell __attribute__ correctlyLibravatar Jeff King1-1/+1
We want to tell the compiler that error_buf() uses printf()-style arguments via the __attribute__ mechanism, but the original commit (3a429d0), forgot the trailing "__". This happens to work with real GNUC-compatible compilers like gcc and clang, but confuses our fallback macro in git-compat-util.h, which only matches the official name (and thus the build fails on compilers like Visual Studio). Reported-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10Merge branch 'jk/tighten-alloc' into maintLibravatar Junio C Hamano1-8/+5
* jk/tighten-alloc: (23 commits) compat/mingw: brown paper bag fix for 50a6c8e ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow ...
2016-03-06remote: don't resolve HEAD in non-repositoryLibravatar Jeff King1-5/+6
The remote-config code wants to look at HEAD to mark the current branch specially. But if we are not in a repository (e.g., running "git archive --remote"), this makes no sense; there is no HEAD to look at, and we have no current branch. This doesn't really cause any bugs in practice (if you are not in a repo, you probably don't have a .git/HEAD file), but we should be more careful about triggering the refs code at all in a non-repo. As we grow new ref backends, we would not even know which backend to use. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-26Merge branch 'jk/tighten-alloc'Libravatar Junio C Hamano1-8/+5
Update various codepaths to avoid manually-counted malloc(). * jk/tighten-alloc: (22 commits) ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation ...
2016-02-26Merge branch 'tg/git-remote'Libravatar Junio C Hamano1-48/+34
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-22use st_add and st_mult for allocation size computationLibravatar Jeff King1-4/+4
If our size computation overflows size_t, we may allocate a much smaller buffer than we expected and overflow it. It's probably impossible to trigger an overflow in most of these sites in practice, but it is easy enough convert their additions and multiplications into overflow-checking variants. This may be fixing real bugs, and it makes auditing the code easier. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert trivial cases to FLEX_ARRAY macrosLibravatar Jeff King1-4/+1
Using FLEX_ARRAY macros reduces the amount of manual computation size we have to do. It also ensures we don't overflow size_t, and it makes sure we write the same number of bytes that we allocated. Signed-off-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-11/+2
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-02-16remote: use parse_config_keyLibravatar Thomas Gummerer1-37/+32
95b567c7 ("use skip_prefix to avoid repeating strings") transformed calls using starts_with() and then skipping the length of the prefix to skip_prefix() calls. In remote.c there are a few calls like: if (starts_with(foo, "bar")) foo += 3 These calls weren't touched by the aformentioned commit, but can be replaced by calls to parse_config_key(), to simplify the code and clarify the intentions. Do that. Helped-by: Jeff King <peff@peff.net> 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-10Merge branch 'aw/push-force-with-lease-reporting'Libravatar Junio C Hamano1-7/+8
"git push --force-with-lease" has been taught to report if the push needed to force (or fast-forwarded). * aw/push-force-with-lease-reporting: push: fix ref status reporting for --force-with-lease
2016-02-03Merge branch 'kf/http-proxy-auth-methods'Libravatar Junio C Hamano1-0/+3
New http.proxyAuthMethod configuration variable can be used to specify what authentication method to use, as a way to work around proxies that do not give error response expected by libcurl when CURLAUTH_ANY is used. Also, the codepath for proxy authentication has been taught to use credential API to store the authentication material in user's keyrings. * kf/http-proxy-auth-methods: http: use credential API to handle proxy authentication http: allow selection of proxy authentication method
2016-02-01push: fix ref status reporting for --force-with-leaseLibravatar Andrew Wheeler1-7/+8
The --force--with-lease push option leads to less detailed status information than --force. In particular, the output indicates that a reference was fast-forwarded, even when it was force-updated. Modify the --force-with-lease ref status logic to leverage the --force ref status logic when the "lease" conditions are met. Also, enhance tests to validate output status reporting. Signed-off-by: Andrew Wheeler <awheeler@motorola.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26http: allow selection of proxy authentication methodLibravatar Knut Franke1-0/+3
CURLAUTH_ANY does not work with proxies which answer unauthenticated requests with a 307 redirect to an error page instead of a 407 listing supported authentication methods. Therefore, allow the authentication method to be set using the environment variable GIT_HTTP_PROXY_AUTHMETHOD or configuration variables http.proxyAuthmethod and remote.<name>.proxyAuthmethod (in analogy to http.proxy and remote.<name>.proxy). The following values are supported: * anyauth (default) * basic * digest * negotiate * ntlm Signed-off-by: Knut Franke <k.franke@science-computing.de> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-15remote.c: read $GIT_DIR/remotes/* with strbuf_getline()Libravatar Junio C Hamano1-1/+1
These files can be edited with a DOS editor, leaving CR at the end of the line if read with strbuf_getline(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-15strbuf: introduce strbuf_getline_{lf,nul}()Libravatar Junio C Hamano1-2/+2
The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20remote: convert functions to struct object_idLibravatar brian m. carlson1-29/+29
Convert several unsigned char arrays to use struct object_id instead, and change hard-coded 40-based constants to use GIT_SHA1_HEXSZ as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Convert struct object to object_idLibravatar brian m. carlson1-2/+2
struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20ref_newer: convert to use struct object_idLibravatar brian m. carlson1-4/+4
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-29/+29
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-30Merge branch 'rs/pop-commit'Libravatar Junio C Hamano1-4/+2
Code simplification. * rs/pop-commit: use pop_commit() for consuming the first entry of a struct commit_list
2015-10-26use pop_commit() for consuming the first entry of a struct commit_listLibravatar René Scharfe1-4/+2
Instead of open-coding the function pop_commit() just call it. This makes the intent clearer and reduces code size. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-23read_branches_file: plug a FILE* leakLibravatar Johannes Sixt1-0/+1
The earlier rewrite f28e3ab2 (read_branches_file: simplify string handling) of read_branches_file() lost an fclose() call. Put it back. As on Windows files that are open cannot be removed, the leak manifests in a failure of 'git remote rename origin origin' when the remote's URL is specified in .git/branches/origin, because by the time that the command attempts to remove this file, it is still open. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05stat_tracking_info: convert to argv_arrayLibravatar Jeff King1-14/+12
In addition to dropping the magic number for the fixed-size argv, we can also drop a fixed-length buffer and some strcpy's into it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25read_remotes_file: simplify string handlingLibravatar Jeff King1-37/+18
The main motivation for this cleanup is to switch our line-reading to a strbuf, which removes the use of a fixed-size buffer (which limited the size of remote URLs). Since we have the strbuf, we can make use of strbuf_rtrim(). While we're here, we can also simplify the parsing of each line. First, we can use skip_prefix() to avoid some magic numbers. But second, we can avoid splitting the parsing and actions for each line into two stages. Right now we figure out which type of line we have, set an int to a magic number, skip any intermediate whitespace, and then act on the resulting value based on the magic number. Instead, let's factor the whitespace skipping into a function. That lets us avoid the magic numbers and keep the actions close to the parsing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25read_branches_file: simplify string handlingLibravatar Jeff King1-34/+20
This function does a lot of manual string handling, and has some unnecessary limits. This patch cleans up a number of things: 1. Drop the arbitrary 1000-byte limit on the size of the remote name (we do not have such a limit in any of the other remote-reading mechanisms). 2. Replace fgets into a fixed-size buffer with a strbuf, eliminating any limits on the length of the URL. 3. Replace manual whitespace handling with strbuf_trim (since we now have a strbuf). This also gets rid of a call to strcpy, and the confusing reuse of the "p" pointer for multiple purposes. 4. We currently build up the refspecs over multiple strbuf calls. We do this to handle the fact that the URL "frag" may not be present. But rather than have multiple conditionals, let's just default "frag" to "master". This lets us format the refspecs with a single xstrfmt. It's shorter, and easier to see what the final string looks like. We also update the misleading comment in this area (the local branch is named after the remote name, not after the branch name on the remote side). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25replace trivial malloc + sprintf / strcpy calls with xstrfmtLibravatar Jeff King1-6/+1
It's a common pattern to do: foo = xmalloc(strlen(one) + strlen(two) + 1 + 1); sprintf(foo, "%s %s", one, two); (or possibly some variant with strcpy()s or a more complicated length computation). We can switch these to use xstrfmt, which is shorter, involves less error-prone manual computation, and removes many sprintf and strcpy calls which make it harder to audit the code for real buffer overflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-05Merge branch 'bc/object-id'Libravatar Junio C Hamano1-5/+8
for_each_ref() callback functions were taught to name the objects not with "unsigned char sha1[20]" but with "struct object_id". * bc/object-id: (56 commits) struct ref_lock: convert old_sha1 member to object_id warn_if_dangling_symref(): convert local variable "junk" to object_id each_ref_fn_adapter(): remove adapter rev_list_insert_ref(): remove unneeded arguments rev_list_insert_ref_oid(): new function, taking an object_oid mark_complete(): remove unneeded arguments mark_complete_oid(): new function, taking an object_oid clear_marks(): rewrite to take an object_id argument mark_complete(): rewrite to take an object_id argument send_ref(): convert local variable "peeled" to object_id upload-pack: rewrite functions to take object_id arguments find_symref(): convert local variable "unused" to object_id find_symref(): rewrite to take an object_id argument write_one_ref(): rewrite to take an object_id argument write_refs_to_temp_dir(): convert local variable sha1 to object_id submodule: rewrite to take an object_id argument shallow: rewrite functions to take object_id arguments handle_one_ref(): rewrite to take an object_id argument add_info_ref(): rewrite to take an object_id argument handle_one_reflog(): rewrite to take an object_id argument ...
2015-05-25remote: rewrite functions to take object_id argumentsLibravatar Michael Haggerty1-11/+8
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-25each_ref_fn: change to take an object_id parameterLibravatar Michael Haggerty1-2/+8
Change typedef each_ref_fn to take a "const struct object_id *oid" parameter instead of "const unsigned char *sha1". To aid this transition, implement an adapter that can be used to wrap old-style functions matching the old typedef, which is now called "each_ref_sha1_fn"), and make such functions callable via the new interface. This requires the old function and its cb_data to be wrapped in a "struct each_ref_fn_sha1_adapter", and that object to be used as the cb_data for an adapter function, each_ref_fn_adapter(). This is an enormous diff, but most of it consists of simple, mechanical changes to the sites that call any of the "for_each_ref" family of functions. Subsequent to this change, the call sites can be rewritten one by one to use the new interface. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22remote.c: add branch_get_pushLibravatar Jeff King1-0/+85
In a triangular workflow, the place you pull from and the place you push to may be different. As we have branch_get_upstream for the former, this patch adds branch_get_push for the latter (and as the former implements @{upstream}, so will this implement @{push} in a future patch). Note that the memory-handling for the return value bears some explanation. Some code paths require allocating a new string, and some let us return an existing string. We should provide a consistent interface to the caller, so it knows whether to free the result or not. We could do so by xstrdup-ing any existing strings, and having the caller always free. But that makes us inconsistent with branch_get_upstream, so we would prefer to simply take ownership of the resulting string. We do so by storing it inside the "struct branch", just as we do with the upstream refname (in that case we compute it when the branch is created, but there's no reason not to just fill it in lazily in this case). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22remote.c: return upstream name from stat_tracking_infoLibravatar Jeff King1-18/+17
After calling stat_tracking_info, callers often want to print the name of the upstream branch (in addition to the tracking count). To do this, they have to access branch->merge->dst[0] themselves. This is not wrong, as the return value from stat_tracking_info tells us whether we have an upstream branch or not. But it is a bit leaky, as we make an assumption about how it calculated the upstream name. Instead, let's add an out-parameter that lets the caller know the upstream name we found. As a bonus, we can get rid of the unusual tri-state return from the function. We no longer need to use it to differentiate between "no tracking config" and "tracking ref does not exist" (since you can check the upstream_name for that), so we can just use the usual 0/-1 convention for success/error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22remote.c: untangle error logic in branch_get_upstreamLibravatar Jeff King1-6/+13
The error-diagnosis logic in branch_get_upstream was copied straight from sha1_name.c in the previous commit. However, because we check all error cases and upfront and then later diagnose them, the logic is a bit tangled. In particular: - if branch->merge[0] is NULL, we may end up dereferencing it for an error message (in practice, it should never be NULL, so this is probably not a triggerable bug). - We may enter the code path because branch->merge[0]->dst is NULL, but we then start our error diagnosis by checking whether our local branch exists. But that is only relevant to diagnosing missing merge config, not a missing tracking ref; our diagnosis may hide the real problem. Instead, let's just use a sequence of "if" blocks to check for each error type, diagnose it, and return NULL. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21remote.c: report specific errors from branch_get_upstreamLibravatar Jeff King1-4/+29
When the previous commit introduced the branch_get_upstream helper, there was one call-site that could not be converted: the one in sha1_name.c, which gives detailed error messages for each possible failure. Let's teach the helper to optionally report these specific errors. This lets us convert another callsite, and means we can use the helper in other locations that want to give the same error messages. The logic and error messages come straight from sha1_name.c, with the exception that we start each error with a lowercase letter, as is our usual style (note that a few tests need updated as a result). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21remote.c: introduce branch_get_upstream helperLibravatar Jeff King1-3/+9
All of the information needed to find the @{upstream} of a branch is included in the branch struct, but callers have to navigate a series of possible-NULL values to get there. Let's wrap that logic up in an easy-to-read helper. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>