summaryrefslogtreecommitdiff
path: root/transport-helper.c
diff options
context:
space:
mode:
authorJonathan Tan <jonathantanmy@google.com>2018-08-01 20:13:20 (GMT)
committerJunio C Hamano <gitster@pobox.com>2018-08-01 22:00:52 (GMT)
commite2842b39f4168e3cd39a53961c1e50bb940eedf1 (patch)
treeac52bc48a080b2db60a868acb1c3c70711512691 /transport-helper.c
parentcf1e7c07705eb21c30d0ee414810e7bc8fdf7d82 (diff)
downloadgit-e2842b39f4168e3cd39a53961c1e50bb940eedf1.zip
git-e2842b39f4168e3cd39a53961c1e50bb940eedf1.tar.gz
git-e2842b39f4168e3cd39a53961c1e50bb940eedf1.tar.bz2
fetch-pack: unify ref in and out param
When a user fetches: - at least one up-to-date ref and at least one non-up-to-date ref, - using HTTP with protocol v0 (or something else that uses the fetch command of a remote helper) some refs might not be updated after the fetch. This bug was introduced in commit 989b8c4452 ("fetch-pack: put shallow info in output parameter", 2018-06-28) which allowed transports to report the refs that they have fetched in a new out-parameter "fetched_refs". If they do so, transport_fetch_refs() makes this information available to its caller. Users of "fetched_refs" rely on the following 3 properties: (1) it is the complete list of refs that was passed to transport_fetch_refs(), (2) it has shallow information (REF_STATUS_REJECT_SHALLOW set if relevant), and (3) it has updated OIDs if ref-in-want was used (introduced after 989b8c4452). In an effort to satisfy (1), whenever transport_fetch_refs() filters the refs sent to the transport, it re-adds the filtered refs to whatever the transport supplies before returning it to the user. However, the implementation in 989b8c4452 unconditionally re-adds the filtered refs without checking if the transport refrained from reporting anything in "fetched_refs" (which it is allowed to do), resulting in an incomplete list, no longer satisfying (1). An earlier effort to resolve this [1] solved the issue by readding the filtered refs only if the transport did not refrain from reporting in "fetched_refs", but after further discussion, it seems that the better solution is to revert the API change that introduced "fetched_refs". This API change was first suggested as part of a ref-in-want implementation that allowed for ref patterns and, thus, there could be drastic differences between the input refs and the refs actually fetched [2]; we eventually decided to only allow exact ref names, but this API change remained even though its necessity was decreased. Therefore, revert this API change by reverting commit 989b8c4452, and make receive_wanted_refs() update the OIDs in the sought array (like how update_shallow() updates shallow information in the sought array) instead. A test is also included to show that the user-visible bug discussed at the beginning of this commit message no longer exists. [1] https://public-inbox.org/git/20180801171806.GA122458@google.com/ [2] https://public-inbox.org/git/86a128c5fb710a41791e7183207c4d64889f9307.1485381677.git.jonathantanmy@google.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'transport-helper.c')
-rw-r--r--transport-helper.c6
1 files changed, 2 insertions, 4 deletions
diff --git a/transport-helper.c b/transport-helper.c
index 8b5abca..1f8ff7e 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -651,16 +651,14 @@ static int connect_helper(struct transport *transport, const char *name,
}
static int fetch(struct transport *transport,
- int nr_heads, struct ref **to_fetch,
- struct ref **fetched_refs)
+ int nr_heads, struct ref **to_fetch)
{
struct helper_data *data = transport->data;
int i, count;
if (process_connect(transport, 0)) {
do_take_over(transport);
- return transport->vtable->fetch(transport, nr_heads, to_fetch,
- fetched_refs);
+ return transport->vtable->fetch(transport, nr_heads, to_fetch);
}
count = 0;