From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: "Stefan Beller" <sbeller@google.com>,
"Ronnie Sahlberg" <ronniesahlberg@gmail.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Nguyễn Thái Ngọc" <pclouds@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 00/11] Allow reference values to be checked in a transaction
Date: Mon, 09 Feb 2015 12:45:58 -0800 [thread overview]
Message-ID: <xmqqbnl2bypl.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54D91B24.5050808@alum.mit.edu> (Michael Haggerty's message of "Mon, 09 Feb 2015 21:40:04 +0100")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 02/09/2015 08:05 PM, Stefan Beller wrote:
>> On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>>> [...]
>>>> This patch series applies on top of master merged together with
>>>> sb/atomic-push, which in turn depends on mh/reflog-expire.
>>>
>>> I am a bit puzzled by your intentions, so help me out.
>>>
>>> I see that your understanding is that Stefan will be rerolling the
>>> push atomicity thing; wouldn't we then want to have a "fix and
>>> clean" topic like this one first and build the push atomicity thing
>>> on top instead?
>>
>> My understanding is to not reroll origin/sb/atomic-push, but
>> origin/sb/atomic-push-fix (which is worded misleading. It is not about
>> atomic pushes, but about enabling large transactions in my understanding)
>
> Yes, that is what I thought.
> ...
> Both series have to do with reflogs, but they are logically pretty
> independent. In particular, "Fix some problems with reflog expiration"
> fixes problems that existed before mh/reflog-expire. And considering
> that one topic is quite mature whereas the the other is just making its
> debut, it seemed like yoking them together would slow down the first
> topic for no good reason.
> ...
> I expected that mh/reflog-expire and sb/atomic-push would be merged
> pretty early in the 2.4 cycle (they are both in next already). Junio, is
> that not your plan?
OK, I am glad I asked for clarifications. It was that I felt uneasy
to see many new "this cleans and fixes" while there are in-flight
topics in the same area.
Thanks.
prev parent reply other threads:[~2015-02-09 20:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-08 16:13 [PATCH 00/11] Allow reference values to be checked in a transaction Michael Haggerty
2015-02-08 16:13 ` [PATCH 01/11] refs: move REF_DELETING to refs.c Michael Haggerty
2015-02-09 18:09 ` Stefan Beller
2015-02-08 16:13 ` [PATCH 02/11] refs: remove the gap in the REF_* constant values Michael Haggerty
2015-02-09 18:14 ` Stefan Beller
2015-02-08 16:13 ` [PATCH 03/11] struct ref_update: move "have_old" into "flags" Michael Haggerty
2015-02-08 16:13 ` [PATCH 04/11] ref_transaction_update(): remove "have_old" parameter Michael Haggerty
2015-02-09 18:20 ` Stefan Beller
2015-02-11 15:32 ` Michael Haggerty
2015-02-08 16:13 ` [PATCH 05/11] ref_transaction_delete(): " Michael Haggerty
2015-02-09 18:22 ` Stefan Beller
2015-02-08 16:14 ` [PATCH 06/11] commit: add tests of commit races Michael Haggerty
2015-02-09 18:31 ` Stefan Beller
2015-02-10 19:12 ` Junio C Hamano
2015-02-11 15:05 ` Michael Haggerty
2015-02-11 18:10 ` Junio C Hamano
2015-02-11 18:24 ` Stefan Beller
2015-02-11 18:54 ` Junio C Hamano
2015-02-08 16:14 ` [PATCH 07/11] commit: avoid race when creating orphan commits Michael Haggerty
2015-02-09 18:35 ` Stefan Beller
2015-02-11 15:47 ` Michael Haggerty
2015-02-08 16:14 ` [PATCH 08/11] ref_transaction_create(): check that new_sha1 is valid Michael Haggerty
2015-02-09 18:35 ` Stefan Beller
2015-02-08 16:14 ` [PATCH 09/11] ref_transaction_delete(): check that old_sha1 is not null_sha1 Michael Haggerty
2015-02-09 18:37 ` Stefan Beller
2015-02-08 16:14 ` [PATCH 10/11] ref_transaction_verify(): new function to check a reference's value Michael Haggerty
2015-02-09 18:50 ` Stefan Beller
2015-02-11 16:11 ` Michael Haggerty
2015-02-08 16:14 ` [PATCH 11/11] update_ref(): improve documentation Michael Haggerty
2015-02-09 18:51 ` Stefan Beller
2015-02-09 18:41 ` [PATCH 00/11] Allow reference values to be checked in a transaction Junio C Hamano
2015-02-09 19:05 ` Stefan Beller
2015-02-09 20:40 ` Michael Haggerty
2015-02-09 20:41 ` Stefan Beller
2015-02-09 20:45 ` Junio C Hamano [this message]
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=xmqqbnl2bypl.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=pclouds@gmail.com \
--cc=ronniesahlberg@gmail.com \
--cc=sbeller@google.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.