Re: [PATCH 0/5] Start of a journey: drop NO_THE_INDEX_COMPATIBILITY_MACROS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 3, 2017 at 3:27 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Tue, May 2, 2017 at 8:36 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>>
>>> This applies to origin/master.
>>>
>>> For better readability and understandability for newcomers it is a good idea
>>> to not offer 2 APIs doing the same thing with on being the #define of the other.
>>>
>>> In the long run we may want to drop the macros guarded by
>>> NO_THE_INDEX_COMPATIBILITY_MACROS. This converts a couple of them.
>>
>> Why?
>
> Well.. why did you add NO_THE_INDEX_COMP... in the first place? ;-) j/k
>
>> Why should we keep typing &the_index, when most of the time we are given _the_ index and working on it?
>
> I attempted the same thing once or twice in the past, had the same
> impression and dropped it. But I think it's good to get rid of cache_*
> macros, at least outside builtin/ directory. It makes it clearer about
> the index dependency. Maybe one day we could libify sha1_file.c and
> finally introduce "struct repository", where the_index, object db and
> ref-store belong (hmm.. the index may belong to "struct worktree", not
> the repo one...).

+cc Brandon, who attempts to come up with a struct repository as we speak.

> So yeah it may look a bit more verbose (and probably causes a lot more
> conflicts on 'pu') but in my opinion it's a good direction. I wish
> Stefan good luck. Brave soul :D

Thanks for the encouragement! As you seem to be interested in this topic,
you may want to help out by reviewing, starting at:
https://public-inbox.org/git/20170502222322.21055-1-sbeller@xxxxxxxxxx/

Thanks,
Stefan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]