git/remote.c, branch v2.6.2

Merge branch 'bc/object-id'

2015-06-05T19:17:37Z

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 ...

remote: rewrite functions to take object_id arguments

2015-05-25T19:19:34Z

Signed-off-by: Michael Haggerty Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

each_ref_fn: change to take an object_id parameter

2015-05-25T19:19:27Z

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 Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

remote.c: add branch_get_push

2015-05-22T16:33:08Z

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 Signed-off-by: Junio C Hamano

remote.c: return upstream name from stat_tracking_info

2015-05-22T16:32:34Z

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 Signed-off-by: Junio C Hamano

remote.c: untangle error logic in branch_get_upstream

2015-05-22T16:30:51Z

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 Signed-off-by: Junio C Hamano

remote.c: report specific errors from branch_get_upstream

2015-05-21T18:07:46Z

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 Signed-off-by: Junio C Hamano

remote.c: introduce branch_get_upstream helper

2015-05-21T18:04:42Z

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 Signed-off-by: Junio C Hamano

remote.c: hoist read_config into remote_get_1

2015-05-21T18:04:10Z

Before the previous commit, we had to make sure that read_config() was called before entering remote_get_1, because we needed to pass pushremote_name by value. But now that we pass a function, we can let remote_get_1 handle loading the config itself, turning our wrappers into true one-liners. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

remote.c: provide per-branch pushremote name

2015-05-21T18:03:58Z

When remote.c loads its config, it records the branch.*.pushremote for the current branch along with the global remote.pushDefault value, and then binds them into a single value: the default push for the current branch. We then pass this value (which may be NULL) to remote_get_1 when looking up a remote for push. This has a few downsides: 1. It's confusing. The early-binding of the "current value" led to bugs like the one fixed by 98b406f (remote: handle pushremote config in any order, 2014-02-24). And the fact that pushremotes fall back to ordinary remotes is not explicit at all; it happens because remote_get_1 cannot tell the difference between "we are not asking for the push remote" and "there is no push remote configured". 2. It throws away intermediate data. After read_config() finishes, we have no idea what the value of remote.pushDefault was, because the string has been overwritten by the current branch's branch.*.pushremote. 3. It doesn't record other data. We don't note the branch.*.pushremote value for anything but the current branch. Let's make this more like the fetch-remote config. We'll record the pushremote for each branch, and then explicitly compute the correct remote for the current branch at the time of reading. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano