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/18/2018 2:41 PM, Brandon Williams wrote:
On 06/17, Duy Nguyen wrote:
On Sun, Jun 17, 2018 at 9:02 AM Elijah Newren <newren@xxxxxxxxx> wrote:

On Fri, Jun 15, 2018 at 10:41 PM, Nguyễn Thái Ngọc Duy
<pclouds@xxxxxxxxx> 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.

You post this small little patch about unpack-trees.c, mentioning you
don't know if it's even correct, and bait me into reviewing it and
then spring on me that it's actually nearly 100 patches that need
review...   Very sneaky.  ;-)

To be fair, it's all Brandon's fault. If he didn't kick the_index out
of dir.c, it would not conflict with one of my out-of-tree patches in
unpack-trees.c, catch my attention and make me go down this rabbit
hole :D

Haha well this is something I've wanted to do for over a year now, glad
you've decided to run with it :)

I guess I've gotten pretty good at getting people to go down rabbit
holes.  First Stefan with the object store refactoring and now you with
the index stuff.  All because I wanted git to be more object oriented
and have less global state ;)


Let me join the chorus of voices excited to see someone finally taking the plunge to do this! I'm very happy about seeing this taken through to "the end of the_index."



[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