Message ID | 20181019145237.16079-1-pclouds@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Kill the_index, final part | expand |
On Fri, Oct 19, 2018 at 7:52 AM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: > > Stefan I see you start removing more references of the_repository in > another series (haven't really looked at it yet) so this is just heads > up so we could coordinate if needed. Still WIP, not really ready for > review yet. I'll take a brief look anyway, otherwise you wouldn't have put in on a mailing list :-P Yes, coordination would be good; stolee brought up a good point regarding testing these changes. Killing of the index in itself can be just tested by checking if behavior stays the same, but killing of the_repository is a slightly different beast, as it relates to submodules, which means any global state that is still around, need to go into the repository struct (we might have missed some there, whereas the index struct has been around for a long time). > This series removes use of the_index outside builtin/ and t/helper/. > The only the_index reference left is in repository.c. The macro > NO_THE_REPOSITORY_COMPATIBILITY_MACROS is now flipped to > USE_THE_INDEX_COMPATIBILITY_MACROS. "the_index" is forbidden by > default. Wow, that is really cool. Looking forward for the patches. :-) > After this I think we can start pushing the_repository outside library > code. Then perhaps clean them up in builtin code too and you can > finally get rid of it. But I don't think that'll happen in a year's > time. That sounds realistic. Stefan
On Fri, Oct 19, 2018 at 7:38 PM Stefan Beller <sbeller@google.com> wrote: > > On Fri, Oct 19, 2018 at 7:52 AM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: > > > > Stefan I see you start removing more references of the_repository in > > another series (haven't really looked at it yet) so this is just heads > > up so we could coordinate if needed. Still WIP, not really ready for > > review yet. > > I'll take a brief look anyway, otherwise you wouldn't have put in on > a mailing list :-P Thanks. Just fyi. Since there are still plenty conflicts when merging this with 'pu', I'll just wait until things settle a bit in 'master' before resending.