Re: [PATCH 00/15] Kill the_index part 1, expose it

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

 



On 6/16/2018 1:41 AM, Nguyễn Thái Ngọc Duy wrote:
This is the beginning of the end of the_index. The problem with
the_index is it lets library code anywhere access it freely. This is
not good because from high level you may not realize that the_index is
being used while you don't want to touch index at all, or you want to
use a different index instead.

This is a long series, 86 patches [1], so I'm going to split and
submit it in 15-20 patches at a time. The first two parts are trivial
though and could be safely fast tracked if needed.

This is the first part, which kills the use of index compat macros
outside builtin/ and expose the_index in all library code. Later on we
will ban the_index from one file each time until it's gone for good.

"struct index_state *" will be passed from builtin/ through the call
chain to the function that needs it. In some cases, "struct
repository *" will be passed instead when the whole operation spans
more than just the index.  By the end, the_index becomes part of
"index compat macros" and cannot be used outside builtin/

Part one is mechanical conversion with the help of coccinelle. The
only real patches are the first and the last one.

[1] https://gitlab.com/pclouds/git/commits/really-kill-the-index

This is a good series, and a good goal!

Outside of dropping [PATCH 01/15] until all the changes are applied, this patch looks like a good, mechanical change.

There are a lot of cross-cutting changes happening right now, between this series of series and Stefan's series of series. Hopefully after 2.18 is cut, a lot of these can graduate to master quickly. Personally, I find it difficult to base a patch off of multiple in-progress branches and would rather work off of a "known good" point like the tip of master.

Thanks,
-Stolee



[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]

  Powered by Linux