Re: [PATCH v3 0/2] support for filtering trees and blobs based on depth

From: Matthew DeVore <matvore@comcast.net>
Date: Jan 17, 2019, 00:14 UTC
Message-ID: <04d6b46f-da87-bde2-1511-a9f2071bf034@comcast.net>
In-Reply-To: <xmqqbm4hpjyg.fsf@gitster-ct.c.googlers.com>

On 2019/01/15 15:41, Junio C Hamano wrote:

Show 14 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> This is turning out to be messier than I like.
>>
>> The topic is tangled with too many things in flight and I think I
>> reduced its dependencies down to nd/the-index and
>> sb/more-repo-in-api plus then-current tip of master (and that is why
>> it is based on a1411cecc7), but it seems that it wants a bit more
>> than that; builtin/rebase.c at its tip does not even compile, so
>> I'll need to wiggle the topic before it can go to 'next'.
> Half false alarm.  I do need to wiggle the topic, but that was not
> because the choice of base was bad.  It was that nd/the-index plus
> sb/more-repo-in-api had semantic merge conflicts with the then-current
> master.

If I understand right, this is a product of the fact that you had to merge these branches together and base my change on top of them, and that is a result of that fact that I didn't work on top of master for the first iterations of the patch.

Sorry about that. My last re-roll was based on master (commit 77556354) but I guess before I sent that version of the patch set I had already done some damage by working off of next for the earlier patches.

I think my last version of the patch was fine since it was based off master. Let me know if I've misunderstood.

Show 5 quoted lines

>> And worse yet, it seems that filter-options-should-use-plain-int
>> topic depends on this topic in turn as it wants to use
>> LOFC_TREEE_DEPTH.
> This part is still true.  The scaling-factor-over-the-wire topic
> does need to be rebuilt on top of this one.

This seems like a easier problem to understand, but I'm not sure how to avoid this issue in the future.

Thanks, Matt