Re: [PATCH 01/27] *: remove 'const' qualifier for struct index_state

From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, newren@gmail.com,
	Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH 01/27] *: remove 'const' qualifier for struct index_state
Date: Tue, 30 Mar 2021 12:53:59 -0400	[thread overview]
Message-ID: <9cf7775f-189d-8350-ee7a-0bd4444175aa@gmail.com> (raw)
In-Reply-To: <xmqq8s6ilhgs.fsf@gitster.g>

On 3/19/2021 9:52 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>>> From: Derrick Stolee <dstolee@microsoft.com>
>>>
>>> Several methods specify that they take a 'struct index_state' pointer
>>> with the 'const' qualifier because they intend to only query the data,
>>> not change it. However, we will be introducing a step very low in the
>>> method stack that might modify a sparse-index to become a full index in
>>> the case that our queries venture inside a sparse-directory entry.
>>>
>>> This change only removes the 'const' qualifiers that are necessary for
>>> the following change which will actually modify the implementation of
>>> index_name_stage_pos().
>>
>> This step has a bit of interaction with Matheus's "git add/rm" work
>> in sparse checkout (mt/add-rm-in-sparse-checkout), which I believe
>> is still in a bit of flux.  I didn't check potential conflicts the
>> remainder of the series may have with other in-flight topics.
>>
>> So, I may throw review comments at the patches in this topic as if
>> they are standalone, but please do not be upset if it didn't appear
>> in the 'seen' topic.
> 
> Tonight's pushout will have this topic in 'seen', but I consider the
> branch a series of trial merges (there are other first-time topics).
> The result seems to compile for me, but other than that, I have not
> much confidence in conflict resolution.  Please give them an extra
> set of eyeballs.

I looked at your merge, and recreated and equivalent one in my own
merging. Thanks for working through all those details. I trust that
your rerere data will remember those changes and help avoid trouble
when replaying new versions.

Otherwise, I could create a new version of this patch with the
intention of playing directly on top of mt/add-rm-in-sparse-checkout,
then keep future versions of this series on top of a merge of that
series and ds/sparse-index.

I have a v2 of this series ready to send, but I'll give it a day to
see how things shake out on ds/sparse-index and if you have another
suggestion for this conflict.

Thanks,
-Stolee