From: Stefan Beller <sbeller@google.com>
To: gitster@pobox.com, git@jeffhostetler.com
Cc: git@vger.kernel.org, Stefan Beller <sbeller@google.com>
Subject: [PATCH 24/24] cache.h: retire NO_THE_INDEX_COMPATIBILITY_MACROS
Date: Tue, 2 May 2017 15:23:22 -0700 [thread overview]
Message-ID: <20170502222322.21055-25-sbeller@google.com> (raw)
In-Reply-To: <20170502222322.21055-1-sbeller@google.com>
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@google.com>
---
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
prev parent reply other threads:[~2017-05-02 22:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 22:22 [PATCH 00/24] Retire NO_THE_INDEX_COMPATIBILITY_MACROS Stefan Beller
2017-05-02 22:22 ` [PATCH 01/24] cache.h: drop read_cache() Stefan Beller
2017-05-02 22:23 ` [PATCH 02/24] cache.h: drop active_* macros Stefan Beller
2017-05-02 22:23 ` [PATCH 03/24] cache.h: drop read_cache_from Stefan Beller
2017-05-02 22:23 ` [PATCH 04/24] cache.h: drop read_cache_preload(pathspec) Stefan Beller
2017-05-02 22:23 ` [PATCH 05/24] cache.h: drop read_cache_unmerged() Stefan Beller
2017-05-02 22:23 ` [PATCH 06/24] unpack-trees.c: rename parameter 'the_index' Stefan Beller
2017-05-02 22:23 ` [PATCH 07/24] cache.h: drop read_blob_data_from_cache Stefan Beller
2017-05-02 22:23 ` [PATCH 08/24] cache.h: drop unmerge_cache[_entry_at] Stefan Beller
2017-05-02 22:23 ` [PATCH 09/24] cache.h: drop resolve_undo_clear Stefan Beller
2017-05-02 22:23 ` [PATCH 10/24] cache.h: drop cache_name_is_other Stefan Beller
2017-05-02 22:23 ` [PATCH 11/24] cache.h: drop cache_file_exists Stefan Beller
2017-05-02 22:23 ` [PATCH 12/24] cache.h: drop cache_dir_exists Stefan Beller
2017-05-02 22:23 ` [PATCH 13/24] cache.h: drop is_cache_unborn(), discard_cache(), unmerged_cache() Stefan Beller
2017-05-02 22:23 ` [PATCH 14/24] cache.h: drop cache_name_pos Stefan Beller
2017-05-02 22:23 ` [PATCH 15/24] cache.h: drop add_cache_entry Stefan Beller
2017-05-02 22:23 ` [PATCH 16/24] cache.h: drop rename_cache_entry_at Stefan Beller
2017-05-02 22:23 ` [PATCH 17/24] cache.h: drop remove_file_from_cache Stefan Beller
2017-05-02 22:23 ` [PATCH 18/24] cache.h: drop add_to_cache Stefan Beller
2017-05-02 22:23 ` [PATCH 19/24] cache.h: drop add_file_to_cache Stefan Beller
2017-05-02 22:23 ` [PATCH 20/24] cache.h: drop chmod_cache_entry Stefan Beller
2017-05-02 22:23 ` [PATCH 21/24] cache.h: drop refresh_cache Stefan Beller
2017-05-02 22:23 ` [PATCH 22/24] cache.h: drop ce_modified Stefan Beller
2017-05-02 22:23 ` [PATCH 23/24] cache.h: drop ce_match_stat Stefan Beller
2017-05-02 22:23 ` Stefan Beller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170502222322.21055-25-sbeller@google.com \
--to=sbeller@google.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).