Skip to contentSkip to conversation

submodule-config: clarify/cleanup docs and header

PATCH Superseded Stefan Beller 3 participants 6 messages Nov 22, 2016 Documentation

v3 of 4 Superseded Latest is v4 →

lore
Share & tools
lore
#0 lore raw

v3 cover submodule-config: clarify/cleanup docs and header

replacing sb/submodule-config-cleanup

v3:
diff to current origin/sb/submodule-config-cleanup:

Documentation/technical/api-submodule-config.txt +5 -5
index 1df7a827ff..e06a3fd2de 100644
@@ -49,17 +49,17 @@ Functions
 
 `const struct submodule *submodule_from_path(const unsigned char *commit_or_tree, const char *path)`::
 
-	Lookup values for one submodule by its commit_sha1 and path.
+	Lookup values for one submodule by its commit_or_tree and path.
 
 `const struct submodule *submodule_from_name(const unsigned char *commit_or_tree, const char *name)`::
 
 	The same as above but lookup by name.
 
 Whenever a submodule configuration is parsed in `parse_submodule_config_option`
-via e.g. `gitmodules_config()`, it will be overwrite the entry with the sha1
-zeroed out.  So in the normal case, when HEAD:.gitmodules is parsed first and
-then overlayed with the repository configuration, the null_sha1 entry contains
-the local configuration of a submodule (e.g. consolidated values from local git
+via e.g. `gitmodules_config()`, it will be overwrite the null_sha1 entry.
+So in the normal case, when HEAD:.gitmodules is parsed first and then overlayed
+with the repository configuration, the null_sha1 entry contains the local
+configuration of a submodule (e.g. consolidated values from local git
 configuration and the .gitmodules file in the worktree).
 
 For an example usage see test-submodule-config.c.
submodule-config.c +0 -1
index 4c5f5d074b..d88a746c56 100644
@@ -448,7 +448,6 @@ static const struct submodule *config_from(struct submodule_cache *cache,
 
 	/* fill the submodule config into the cache */
 	parameter.cache = cache;
-	// todo: get the actual tree here:
 	parameter.commit_or_tree = commit_or_tree;
 	parameter.gitmodules_sha1 = sha1;
 	parameter.overwrite = 0;

v2:
addressed Jacobs concerns in patch2, fixing all occurrences of commit_sha1.

Thanks,
Stefan

interdiff to v1:

Documentation/technical/api-submodule-config.txt +1 -1
index 1df7a827ff..a91c1f085e 100644
@@ -49,7 +49,7 @@ Functions
 
 `const struct submodule *submodule_from_path(const unsigned char *commit_or_tree, const char *path)`::
 
-       Lookup values for one submodule by its commit_sha1 and path.
+       Lookup values for one submodule by its commit_or_tree and path.
 
 `const struct submodule *submodule_from_name(const unsigned char *commit_or_tree, const char *name)`::
 

v1:
A small series that would have helped me understand the submodule config once again.

Thanks,
Stefan

Stefan Beller (3):
submodule config: inline config_from_{name, path}
submodule-config: rename commit_sha1 to commit_or_tree
submodule-config: clarify parsing of null_sha1 element

 Documentation/technical/api-submodule-config.txt | 13 ++++--
 submodule-config.c                               | 58 ++++++++++--------------
 submodule-config.h                               |  4 +-
 t/t7411-submodule-config.sh                      | 11 +++++
 4 files changed, 44 insertions(+), 42 deletions(-)
Signature · 1 line
2.11.0.rc2.18.g0126045.dirty
#1 lore raw

PATCH v3 1/3 submodule config: inline config_from_{name, path}

There is no other user of config_from_{name, path}, such that there is no reason for the existence of these one liner functions. Just inline these to increase readability.

---
 submodule-config.c | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)
submodule-config.c +2 -14
index 098085be69..15ffab6af4 100644
@@ -471,18 +471,6 @@ static const struct submodule *config_from(struct submodule_cache *cache,
 	return submodule;
 }
 
-static const struct submodule *config_from_path(struct submodule_cache *cache,
-		const unsigned char *commit_sha1, const char *path)
-{
-	return config_from(cache, commit_sha1, path, lookup_path);
-}
-
-static const struct submodule *config_from_name(struct submodule_cache *cache,
-		const unsigned char *commit_sha1, const char *name)
-{
-	return config_from(cache, commit_sha1, name, lookup_name);
-}
-
 static void ensure_cache_init(void)
 {
 	if (is_cache_init)
@@ -508,14 +496,14 @@ const struct submodule *submodule_from_name(const unsigned char *commit_sha1,
 		const char *name)
 {
 	ensure_cache_init();
-	return config_from_name(&the_submodule_cache, commit_sha1, name);
+	return config_from(&the_submodule_cache, commit_sha1, name, lookup_name);
 }
 
 const struct submodule *submodule_from_path(const unsigned char *commit_sha1,
 		const char *path)
 {
 	ensure_cache_init();
-	return config_from_path(&the_submodule_cache, commit_sha1, path);
+	return config_from(&the_submodule_cache, commit_sha1, path, lookup_path);
 }
 
 void submodule_free(void)
Signature · 1 line
2.11.0.rc2.18.g0126045.dirty
#2 lore raw

PATCH v3 2/3 submodule-config: rename commit_sha1 to commit_or_tree

In reply to Stefan Beller

It is also possible to pass in a tree hash to lookup a submodule config. Make it clear by naming the variables accrodingly. Looking up a submodule config by tree hash will come in handy in a later patch.

---
 Documentation/technical/api-submodule-config.txt |  8 ++---
 submodule-config.c                               | 46 ++++++++++++------------
 submodule-config.h                               |  4 +--
 t/t7411-submodule-config.sh                      | 11 ++++++
 4 files changed, 40 insertions(+), 29 deletions(-)
Documentation/technical/api-submodule-config.txt +4 -4
index 941fa178dd..768458580f 100644
@@ -47,15 +47,15 @@ Functions
 	Can be passed to the config parsing infrastructure to parse
 	local (worktree) submodule configurations.
 
-`const struct submodule *submodule_from_path(const unsigned char *commit_sha1, const char *path)`::
+`const struct submodule *submodule_from_path(const unsigned char *commit_or_tree, const char *path)`::
 
-	Lookup values for one submodule by its commit_sha1 and path.
+	Lookup values for one submodule by its commit_or_tree and path.
 
-`const struct submodule *submodule_from_name(const unsigned char *commit_sha1, const char *name)`::
+`const struct submodule *submodule_from_name(const unsigned char *commit_or_tree, const char *name)`::
 
 	The same as above but lookup by name.
 
-If given the null_sha1 as commit_sha1 the local configuration of a
+If given the null_sha1 as commit_or_tree the local configuration of a
 submodule will be returned (e.g. consolidated values from local git
 configuration and the .gitmodules file in the worktree).
 
submodule-config.c +23 -23

162 lines not on this page · raw message

submodule-config.h +2 -2
index d05c542d2c..99df8e593c 100644
@@ -25,9 +25,9 @@ struct submodule {
 int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
 int parse_push_recurse_submodules_arg(const char *opt, const char *arg);
 int parse_submodule_config_option(const char *var, const char *value);
-const struct submodule *submodule_from_name(const unsigned char *commit_sha1,
+const struct submodule *submodule_from_name(const unsigned char *commit_or_tree,
 		const char *name);
-const struct submodule *submodule_from_path(const unsigned char *commit_sha1,
+const struct submodule *submodule_from_path(const unsigned char *commit_or_tree,
 		const char *path);
 void submodule_free(void);
 
t/t7411-submodule-config.sh +11 -0
index 47562ce465..301ed5e48f 100755
@@ -93,6 +93,17 @@ test_expect_success 'error message contains blob reference' '
 	)
 '
 
+test_expect_success 'using tree sha1 works' '
+	(
+		cd super &&
+		tree=$(git rev-parse HEAD^{tree}) &&
+		commit=$(git rev-parse HEAD^{commit}) &&
+		test-submodule-config $commit b >expect &&
+		test-submodule-config $tree b >actual &&
+		test_cmp expect actual
+	)
+'
+
 cat >super/expect_url <<EOF
 Submodule url: '[email protected]:a.git' for path 'b'
 Submodule url: '[email protected]:submodule.git' for path 'submodule'
Signature · 1 line
2.11.0.rc2.18.g0126045.dirty
#3 lore raw

PATCH v3 3/3 submodule-config: clarify parsing of null_sha1 element

In reply to Stefan Beller
---
 Documentation/technical/api-submodule-config.txt | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Documentation/technical/api-submodule-config.txt +5 -2
index 768458580f..e06a3fd2de 100644
@@ -55,8 +55,11 @@ Functions
 
 	The same as above but lookup by name.
 
-If given the null_sha1 as commit_or_tree the local configuration of a
-submodule will be returned (e.g. consolidated values from local git
+Whenever a submodule configuration is parsed in `parse_submodule_config_option`
+via e.g. `gitmodules_config()`, it will be overwrite the null_sha1 entry.
+So in the normal case, when HEAD:.gitmodules is parsed first and then overlayed
+with the repository configuration, the null_sha1 entry contains the local
+configuration of a submodule (e.g. consolidated values from local git
 configuration and the .gitmodules file in the worktree).
 
 For an example usage see test-submodule-config.c.
Signature · 1 line
2.11.0.rc2.18.g0126045.dirty
#4 lore raw

Re: [PATCHv3 3/3] submodule-config: clarify parsing of null_sha1 element

Documentation/technical/api-submodule-config.txt Functions · line 59

Quoted 2 lines · Stefan Beller
Documentation/technical/api-submodule-config.txt +2 -0
+Whenever a submodule configuration is parsed in `parse_submodule_config_option`
+via e.g. `gitmodules_config()`, it will be overwrite the null_sha1 entry.

It will overwrite? It will be overwritten? I guess it is the latter?

Quoted 6 lines
Documentation/technical/api-submodule-config.txt +3 -0
+So in the normal case, when HEAD:.gitmodules is parsed first and then overlayed
+with the repository configuration, the null_sha1 entry contains the local
+configuration of a submodule (e.g. consolidated values from local git
 configuration and the .gitmodules file in the worktree).
 
 For an example usage see test-submodule-config.c.
#5 lore raw

Re: [PATCHv3 3/3] submodule-config: clarify parsing of null_sha1 element

Quoted 7 lines · Junio C Hamano

Documentation/technical/api-submodule-config.txt Functions · line 59

Quoted 2 lines · Stefan Beller
Documentation/technical/api-submodule-config.txt +2 -0
+Whenever a submodule configuration is parsed in `parse_submodule_config_option`
+via e.g. `gitmodules_config()`, it will be overwrite the null_sha1 entry.

It will overwrite? It will be overwritten? I guess it is the latter?

Quoted 6 lines

Documentation/technical/api-submodule-config.txt Functions · line 65

Quoted 6 lines
Documentation/technical/api-submodule-config.txt +3 -0
+So in the normal case, when HEAD:.gitmodules is parsed first and then overlayed
+with the repository configuration, the null_sha1 entry contains the local
+configuration of a submodule (e.g. consolidated values from local git
 configuration and the .gitmodules file in the worktree).
 
 For an example usage see test-submodule-config.c.

I brought this up in v2, he must have just missed it for v3.

Signature · 1 line
Brandon Williams