From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Stefan Beller <sbeller@google.com>,
ronniesahlberg@gmail.com, jrnieder@gmail.com,
sunshine@sunshineco.com, git@vger.kernel.org,
Ronnie Sahlberg <sahlberg@google.com>
Subject: Re: [PATCH 1/7] receive-pack.c: add protocol support to negotiate atomic-push
Date: Tue, 30 Dec 2014 08:47:05 -0800 [thread overview]
Message-ID: <xmqqvbktrsom.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <549A6C4C.8000905@alum.mit.edu> (Michael Haggerty's message of "Wed, 24 Dec 2014 08:33:32 +0100")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> If I understand correctly, after this patch the server advertises the
> "atomic" capability even though it doesn't actually have that ability
> until a later patch. It seems to me that the order of the patches should
> be reversed: don't advertise the capability before it is actually
> implemented. Why? Bisection. Between the two patches the server is buggy.
That is a valid point. It also reminds us of another thing.
We would need a way to test interoperability among the three new
combinations (i.e. new and old receive-pack talking to new and old
"git push"). We can control what the sender talks on the wire by
giving or not giving "--atomic" option on the command line, but
there should be a way for us to control what the receiver talks on
the wire, i.e. "receivepack.pushAtomic = false" that tells us not to
advertise the "atomic push" capability over the wire, even if you
are running the updated "receive-pack" binary.
This will not only for testing. When we discover that "atomic"
support is undesirable for whatever reason (e.g. the transaction
machinery may consume too many file descriptors without a good
reason), we would need a way for users to disable it until the
problem is fixed.
And of course the tests should make sure that
(1) "git push --atomic" that talks with the receiving end that has
receivepack.pushAtomic set to false behaves as we desire (error
out? degrade to non-atomic? --- whichever way we decide).
(2) "git push" that talks with the receiving end with "atomic" enabled
does not do an atomic push, i.e. try to push two refs, one that
fast forwards and the other that does not, and see one ref is
updated while the other ref remains intact and "git push"
itself reports failured.;
(3) "git push --atomic" that talks with the receiving end with
"atomic" enabled does the atomic thing.
among other things.
next prev parent reply other threads:[~2014-12-30 16:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 19:38 [PATCHv6 0/7] atomic pushes Stefan Beller
2014-12-19 19:38 ` [PATCH 1/7] receive-pack.c: add protocol support to negotiate atomic-push Stefan Beller
2014-12-22 22:52 ` Eric Sunshine
2014-12-23 2:09 ` Stefan Beller
2014-12-24 7:33 ` Michael Haggerty
2014-12-30 16:47 ` Junio C Hamano [this message]
2014-12-19 19:38 ` [PATCH 2/7] send-pack: Rename ref_update_to_be_sent to check_to_send_update Stefan Beller
2014-12-19 19:38 ` [PATCH 3/7] send-pack.c: add --atomic command line argument Stefan Beller
2014-12-22 22:58 ` Eric Sunshine
2014-12-19 19:38 ` [PATCH 4/7] receive-pack.c: receive-pack.c: use a single ref_transaction for atomic pushes Stefan Beller
2014-12-23 1:31 ` Eric Sunshine
2014-12-19 19:38 ` [PATCH 5/7] receive-pack: move execute_commands_non_atomic before execute_commands Stefan Beller
2014-12-22 18:19 ` Junio C Hamano
2014-12-24 0:30 ` Stefan Beller
2014-12-19 19:39 ` [PATCH 6/7] push.c: add an --atomic argument Stefan Beller
2014-12-26 7:17 ` Michael Haggerty
2014-12-29 18:14 ` Stefan Beller
2014-12-29 20:33 ` Junio C Hamano
2014-12-19 19:39 ` [PATCH 7/7] t5543-atomic-push.sh: add basic tests for atomic pushes Stefan Beller
2014-12-22 18:24 ` [PATCHv6 0/7] " Junio C Hamano
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=xmqqvbktrsom.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=ronniesahlberg@gmail.com \
--cc=sahlberg@google.com \
--cc=sbeller@google.com \
--cc=sunshine@sunshineco.com \
/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.