refs.h: rename submodule arguments to submodule_path
PATCH 1/1 refs.h: rename submodule arguments to submodule_path
In submodule land we carefully need to distinguish between the path of a submodule and its name.
The path of a submodule is the path that is recorded in the working tree of the superproject and describes where the submodule is bound to the superprojects tree.
The name as introduced in 941987a554 (git-submodule: give submodules proper names, 2007-06-11) exists to track submodules across renames of submodules. It is also used for the internal path in .git/modules/<name> to store the git directory of the submodule inside the superproject.
When looking up ref functions to use, I was confused which of the two submodule properties are meant in the argument of the ref functions. The context in which the functions were used however revealed it is the path of the submodules.
Rename the arguments to clearly describe what is expected as an input argument.
--- refs.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
refs.h +7 -7
@@ -86,7 +86,7 @@ int peel_ref(const char *refname, unsigned char *sha1);* successful, return 0 and set sha1 to the name of the object; * otherwise, return a non-zero value. */ -int resolve_gitlink_ref (const char *submodule,const char *refname, +int resolve_gitlink_ref (const char *submodule_path,const char *refname,unsigned char *sha1);/*
@@ -204,16 +204,16 @@ int for_each_glob_ref(each_ref_fn fn, const char *pattern, void *cb_data);int for_each_glob_ref_in (each_ref_fn fn,const char *pattern,const char *prefix,void *cb_data); -int head_ref_submodule (const char *submodule,each_ref_fn fn,void *cb_data); -int for_each_ref_submodule (const char *submodule, +int head_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); +int for_each_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); -int for_each_ref_in_submodule (const char *submodule,const char *prefix, +int for_each_ref_in_submodule (const char *submodule_path,const char *prefix,each_ref_fn fn,void *cb_data); -int for_each_tag_ref_submodule (const char *submodule, +int for_each_tag_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); -int for_each_branch_ref_submodule (const char *submodule, +int for_each_branch_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); -int for_each_remote_ref_submodule (const char *submodule, +int for_each_remote_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data);int head_ref_namespaced (each_ref_fn fn,void *cb_data);
Signature · 1 line
2.12.2.603.g7b28dc31ba
+ Junio
Quoted 64 lines · Stefan Beller
In submodule land we carefully need to distinguish between the path of a submodule and its name.
The path of a submodule is the path that is recorded in the working tree of the superproject and describes where the submodule is bound to the superprojects tree.
The name as introduced in
941987a554(git-submodule: give submodules proper names, 2007-06-11) exists to track submodules across renames of submodules. It is also used for the internal path in .git/modules/<name> to store the git directory of the submodule inside the superproject.When looking up ref functions to use, I was confused which of the two submodule properties are meant in the argument of the ref functions. The context in which the functions were used however revealed it is the path of the submodules.
Rename the arguments to clearly describe what is expected as an input argument.
Signed-off-by Stefan Beller <[email protected]>--- refs.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)refs.h +7
-8@@ -86,7 +86,7 @@ int peel_ref(const char *refname, unsigned char *sha1);* successful, return 0 and set sha1 to the name of the object; * otherwise, return a non-zero value. */ -int resolve_gitlink_ref (const char *submodule,const char *refname, +int resolve_gitlink_ref (const char *submodule_path,const char *refname,unsigned char *sha1);/* @@ -204,16 +204,16 @@ int for_each_glob_ref(each_ref_fn fn, const char *pattern, void *cb_data);int for_each_glob_ref_in (each_ref_fn fn,const char *pattern,const char *prefix,void *cb_data); -int head_ref_submodule (const char *submodule,each_ref_fn fn,void *cb_data); -int for_each_ref_submodule (const char *submodule, +int head_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); +int for_each_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); -int for_each_ref_in_submodule (const char *submodule,const char *prefix, +int for_each_ref_in_submodule (const char *submodule_path,const char *prefix,each_ref_fn fn,void *cb_data); -int for_each_tag_ref_submodule (const char *submodule, +int for_each_tag_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); -int for_each_branch_ref_submodule (const char *submodule, +int for_each_branch_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data); -int for_each_remote_ref_submodule (const char *submodule, +int for_each_remote_ref_submodule (const char *submodule_path,each_ref_fn fn,void *cb_data);int head_ref_namespaced (each_ref_fn fn,void *cb_data); --2.12.2.603.g7b28dc31ba
Quoted 1 line · Stefan Beller
+ Junio
Just like Michael, I do not have strong enough opinion for or against this patch to comment on it.
I do agree with you that it would be a good longer-term direction to use "submodule" for a "struct submodule" (i.e. submodule object), and call a string that names a submodule either "submodule_name" or "submodule_path" depending on how it names one, for maintainability of the code.
However I am not convinced that this patch is an improvement. Even though parameter names in decls only serve documentation purpose and it is even OK to only have type without name there, if we are going to _have_ names, it would make sense to match them to the parameter names actually used in the implementation.
Updating these names used in refs.c would make a very noisy patch, of course. But I am not sure if it is a good middle ground to avoid that and to update only refs.h.
Quoted 19 lines · Junio C Hamano
Quoted 1 line · Stefan Beller
+ Junio
Just like Michael, I do not have strong enough opinion for or against this patch to comment on it.
I do agree with you that it would be a good longer-term direction to use "submodule" for a "struct submodule" (i.e. submodule object), and call a string that names a submodule either "
submodule_name" or "submodule_path" depending on how it names one, for maintainability of the code.However I am not convinced that this patch is an improvement. Even though parameter names in decls only serve documentation purpose and it is even OK to only have type without name there, if we are going to _have_ names, it would make sense to match them to the parameter names actually used in the implementation.
Quoted 3 lines
Updating these names used in
refs.cwould make a very noisy patch, of course. But I am not sure if it is a good middle ground to avoid that and to update onlyrefs.h.
One should never infer too much from my silence. As often as not it's because I'm simply busy with other things.
But in this case Junio's right. I think it is a good idea to use argument names in declarations as documentation, and I also agree that it is a minus for the names in the declarations not to agree with the names in the definition. But the code that would have to be touched already has a lot of work going on in it, so conflicts would be likely.
I've CCed Duy because I don't know whether he has more plans regarding submodule references. A natural followup to his recent work would be to add a feature to the submodule module that allows a caller to look up the ref_store object for the submodule. Then client code could use the refs_for_each_ref(struct ref_store *, ...) family of functions to access such references, and we could get rid of the for_each_ref_submodule() family of functions entirely.
So perhaps the code that this patch touches won't be around long anyway.
Michael
Quoted 6 lines · Michael Haggerty
[...]
I've CCed Duy because I don't know whether he has more plans regarding submodule references [...] get rid of thefor_each_ref_submodule()family of functions entirely.So perhaps the code that this patch touches won't be around long anyway.
Oh yeah, he has done exactly that in his nd/prune-in-worktree patch series. (I knew I'd seen that somewhere...)
So it seems that the argument renaming has mostly been overtaken by events, though even after Duy's patch series there are a few const char *submodule arguments that could be renamed.
Michael
Quoted 6 lines · Michael Haggerty
Quoted 5 lines · Michael Haggerty
[...]
I've CCed Duy because I don't know whether he has more plans regarding submodule references [...] get rid of thefor_each_ref_submodule()family of functions entirely.
Quoted 8 lines
Quoted 1 line
So perhaps the code that this patch touches won't be around long anyway.
Oh yeah, he has done exactly that in his nd/prune-in-worktree patch series. (I knew I'd seen that somewhere...)
So it seems that the argument renaming has mostly been overtaken by events, though even after Duy's patch series there are a few
const char *submodulearguments that could be renamed.
Yeah. After that series, the only place that takes a submodule (path) is get_submodule_ref_store() (other functions are just helpers). Renaming it to submodule_path makes perfect sense. Johannes Sixt when reviewing that series also noticed the "path" nature of this "submodule" argument and suggested converting submodule[x] == '/' to is_dir_sep(submodule[i]) for that reason.
At this point, I think Stefan even has the opportunity to reference/look up a submodule ref store by something other than a path
(like "struct submodule *", or by name) if he wants to. But if you
do that, maybe rename the current function to get_submodule_ref_store_by_path() before you add a new get_submodule_ref_store_by_whatever().
About ".. because I don't know whether he (Duy) has more plans regarding submodule references", I plan to convert "submodule[x] == '/'" to is_dir_sep(submodule[x]), but I think that's about it. I'm not involved much in submodule to see the direction it's heading. As far as refs code is concerned, a "struct ref_store *" is all it needs, regardless of how you obtain it.
Signature · 1 line
Duy