[PATCH 24/24] cache.h: retire NO_THE_INDEX_COMPATIBILITY_MACROS

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

 



The NO_THE_INDEX_COMPATIBILITY_MACROS pre processor setting was introduced
in 4aab5b46f4 (Make read-cache.c "the_index" free., 2007-04-01), stating:

    This makes all low-level functions defined in read-cache.c to
    take an explicit index_state structure as their first parameter,
    to specify which index to work on.

The reasoning is very vague, maybe indicating that having the index
specified to work on is easier to for the new reader to understand what
is going on.

All preceding patches worked on retiring functions that do not take an
explicit index as to where to perform its work. Spelling out the reasons
why we want to specify the index at each call:

1)  Ease of understanding:
   The recent patches dropped a lot of macros that may confuse new people
   diving into the code base.
2a) Spelling out global state explicitly:
   Anything you do in submodule land today needs to spawn new processes in
   the submodule. This is cumbersome and not performant. So we may want to
   have an abstraction of a repo, i.e. all repository state in one struct.
   That way we can open a submodule in-process and perform the required
   actions without spawning a process. The road to this future is a long
   road, and we have to start somewhere. Exposing the global state seems
   like a good starter point.
2b) Spelling out global state explicitly (II): (Jeff Hostetler wrote)
   In addition to (eventually) allowing multiple repos be open at the same
   time for submodules, it would also help with various multi-threading
   efforts.  For example, we have loops that do a
   "for (k = 0, k < active_nr; k++) {...}"  There is no visual clue in that
   code that it references "the_index" and therefore should be subject to
   the same locking.  Granted, this is a trivial example, but goes to the
   argument that the code has lots of subtle global variables and macros
   that make it difficult to reason about the code.

   This step would help un-hide this.

Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
---
 attr.c         | 1 -
 cache.h        | 4 ----
 name-hash.c    | 1 -
 read-cache.c   | 1 -
 unpack-trees.c | 1 -
 5 files changed, 8 deletions(-)

diff --git a/attr.c b/attr.c
index 7e2134471c..3decf432b8 100644
--- a/attr.c
+++ b/attr.c
@@ -7,7 +7,6 @@
  * an insanely large number of attributes.
  */
 
-#define NO_THE_INDEX_COMPATIBILITY_MACROS
 #include "cache.h"
 #include "exec_cmd.h"
 #include "attr.h"
diff --git a/cache.h b/cache.h
index f2a45eda9a..f4b7b8621c 100644
--- a/cache.h
+++ b/cache.h
@@ -352,10 +352,6 @@ extern void add_name_hash(struct index_state *istate, struct cache_entry *ce);
 extern void remove_name_hash(struct index_state *istate, struct cache_entry *ce);
 extern void free_name_hash(struct index_state *istate);
 
-
-#ifndef NO_THE_INDEX_COMPATIBILITY_MACROS
-#endif
-
 enum object_type {
 	OBJ_BAD = -1,
 	OBJ_NONE = 0,
diff --git a/name-hash.c b/name-hash.c
index 39309efb7f..02870c1d19 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -5,7 +5,6 @@
  *
  * Copyright (C) 2008 Linus Torvalds
  */
-#define NO_THE_INDEX_COMPATIBILITY_MACROS
 #include "cache.h"
 
 struct dir_entry {
diff --git a/read-cache.c b/read-cache.c
index 6681376f5b..e0c6f3ca11 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -3,7 +3,6 @@
  *
  * Copyright (C) Linus Torvalds, 2005
  */
-#define NO_THE_INDEX_COMPATIBILITY_MACROS
 #include "cache.h"
 #include "tempfile.h"
 #include "lockfile.h"
diff --git a/unpack-trees.c b/unpack-trees.c
index 3dd8f60fc1..41956c4b37 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1,4 +1,3 @@
-#define NO_THE_INDEX_COMPATIBILITY_MACROS
 #include "cache.h"
 #include "dir.h"
 #include "tree.h"
-- 
2.13.0.rc1.39.ga6db8bfa24




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