From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH] send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher
Date: Tue, 12 Aug 2014 15:13:27 -0700 [thread overview]
Message-ID: <xmqqr40l4arc.fsf@gitster.dls.corp.google.com> (raw)
This is more of an RFH than a PATCH. I think we would want to
encapsulate the logic to set STATUS_REJECT_NODELETE in
set_ref_status_for_push() function, but I do not see a good code
structure to do so, given the constraints of the dataflow (i.e. the
protocol capability is only inspected here with server_supports()).
The motivation behind this patch is that I want to move the "Among
refs on remote_refs list, these are not going to be updated on the
remote end" logic into a separate helper function in the next step
and call that before we enter in this per-ref main loop.
-- >8 --
20e8b465 (refactor ref status logic for pushing, 2010-01-08)
restructured the code to set status for each ref to be pushed, but
did not quite go far enough. We inspect the status set earlier by
set_refs_status_for_push() and then perform yet another update to
the status of a ref with an otherwise OK status to be deleted to
mark it with REF_STATUS_REJECT_NODELETE when the protocol tells us
never to delete.
Split the latter into a separate loop that comes before we enter the
per-ref loop. This way we would have one less condition to check in
the main loop.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
send-pack.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 6129b0f..51497c3 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -231,6 +231,14 @@ int send_pack(struct send_pack_args *args,
return 0;
}
+ /*
+ * Why is delete-refs so specific to send-pack machinery
+ * that set_ref_status_for_push() cannot set this bit for us???
+ */
+ for (ref = remote_refs; ref; ref = ref->next)
+ if (ref->deletion && !allow_deleting_refs)
+ ref->status = REF_STATUS_REJECT_NODELETE;
+
if (!args->dry_run)
advertise_shallow_grafts_buf(&req_buf);
@@ -249,17 +257,13 @@ int send_pack(struct send_pack_args *args,
case REF_STATUS_REJECT_FETCH_FIRST:
case REF_STATUS_REJECT_NEEDS_FORCE:
case REF_STATUS_REJECT_STALE:
+ case REF_STATUS_REJECT_NODELETE:
case REF_STATUS_UPTODATE:
continue;
default:
; /* do nothing */
}
- if (ref->deletion && !allow_deleting_refs) {
- ref->status = REF_STATUS_REJECT_NODELETE;
- continue;
- }
-
if (!ref->deletion)
new_refs++;
--
2.1.0-rc2-243-g9c8a734
reply other threads:[~2014-08-12 22:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqr40l4arc.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.