[PATCH] refs.h: rename submodule arguments to submodule_path

[PATCH] refs.h: rename submodule arguments to submodule_path

[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 <sbeller@google.com>
---
 refs.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/refs.h b/refs.h
index 3df0d45ebb..451f92958a 100644
--- a/refs.h
+++ b/refs.h
@@ -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

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

[Stefan Beller]

+ Junio

On Wed, Apr 12, 2017 at 1:00 PM, Stefan Beller <sbeller@google.com> wrote:
> 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 <sbeller@google.com>
> ---
>  refs.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/refs.h b/refs.h
> index 3df0d45ebb..451f92958a 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -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
>

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> + 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.

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

[Michael Haggerty]

On 04/21/2017 03:12 AM, Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:
> 
>> + 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.

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

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

[Michael Haggerty]

On 04/21/2017 08:32 AM, Michael Haggerty wrote:
> [...]
> I've CCed Duy because I don't know whether he has more plans regarding
> submodule references [...] 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.

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

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

[Duy Nguyen]

On Fri, Apr 21, 2017 at 1:42 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 04/21/2017 08:32 AM, Michael Haggerty wrote:
>> [...]
>> I've CCed Duy because I don't know whether he has more plans regarding
>> submodule references [...] 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.
>
> 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.

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.
-- 
Duy