Re: [PATCH 00/11] Allow reference values to be checked in a transaction

[Michael Haggerty <mhagger@alum.mit.edu>]

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.

>> In other words, would it make sense to extend mh/reflog-expire (in
>> 'next') topic with commits from "Fix some problems with reflog
>> expiration (8 patches)" series and this series to fix and clean it?

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 am not sure what advantages this would bring. A better history
> for bisection? I cannot speak for Michael, but my understanding was
> to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3
> is out and everything else on top is unclear/rerolled/discussed as needed.

Stefan, I think you mean sb/atomic-push, not sb/atomic-push-fix, right?

>> We may even want to rebase/reroll mh/reflog-expire on top of v2.3
>> while doing so to adjust to the transaction stuff, if that makes
>> some of the changes in the two new series unnecessary (if these "fix
>> and clean up" changes made in mh/reflog-expire in 'next', that is).

I see all of these topics as pretty independent, though given that they
touch similar areas of the code they often have annoying (but small)
conflicts with each other.

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?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu