Re: [GSoC][PATCH 04/13] submodule: port submodule subcommand 'status' from shell to C

> On Mon, Jul 31, 2017 at 1:56 PM, Prathamesh Chavan <pc44800@gmail.com> wrote:
>> This aims to make git-submodule 'status' a built-in. Hence, the function
>> cmd_status() is ported from shell to C. This is done by introducing
>> three functions: module_status(), submodule_status() and print_status().
>>
>> The function module_status() acts as the front-end of the subcommand.
>> It parses subcommand's options and then calls the function
>> module_list_compute() for computing the list of submodules. Then
>> this functions calls for_each_submodule_list() looping through the
>> list obtained.
>>
>> Then for_each_submodule_list() calls submodule_status() for each of the
>> submodule in its list. The function submodule_status() is responsible
>> for generating the status each submodule it is called for, and
>> then calls print_status().
>>
>> Finally, the function print_status() handles the printing of submodule's
>> status.
>>
>> Mentored-by: Christian Couder <christian.couder@gmail.com>
>> Mentored-by: Stefan Beller <sbeller@google.com>
>> Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
>> ---
>> In this new version, the following changes have been made:
>> * parameters passed to the function print_status() have been changed.
>>   Instead of passing char *sub_sha1, instead the object_id is being passed.
>>
>> * Also, since the passed parameter displaypath's value isn't changed
>>   by the function, it is passed to the funcition as const char *displaypath
>>   instead of char *displaypath.
>>
>> * the output type of the function handle_submodule_head_ref() is changed
>>   from strbuf to object_id, as we will use the object_id instead of the
>>   hex of sha1 being stored in a struct strbuf.
>>
>> * diff_files_args is cleared after using it by passing it as args in the
>>   function cmd_diff_files.
>>
>> * In the function status_submodule(), for checking if a submodule has merge
>>   conflicts, the patch currently checks if the value of any of the ce_flags
>>   is non-zero. Currently, I think the we aren't interested in a partiular flag,
>>   but I'm not sure on this.
>>
>> * Debugging leftovers and suprious new-lines are removed.
>>
>> * The confusion with displaypath being passed as te super-prefix in many
>>   of the ported subcommands may be a result of the fact that the
>>   function generating the displaypath: get_submodule_displaypath()
>>   uses the super-prefix as simply a path concatenated with the current
>>   submodule name to denote our current location.
>>   The function get_super_prefix() is declared in cache.h and defined in
>>   environment.c, but is majorly used in the builtin/submodule--helper.c
>>   and also in unpack-trees.c
>>   Also, for generating any submodule's displaypath, it would be important to
>>   have ".." passed to the submodule, and currently it is possible only via the
>>   super-prefix.
>>   This is also other instaces where the super-prefix contained ".." as well.
>>   One of such instance is Test 4 from t7406-submodule-update.sh
>>   Hence, maybe documenting the value of displaypath might a solution
>>   for the above problem.
>>   I'm just stating my views and would like to recieve your opinion on this
>>   matter.
>
> Yes, I agree that the display path is not quite easily understood as it can be
> ambiguous.  I am confused by this paragraph:
> * does test 4 from 7406 fail here, or was it just the starting point
>   of the discussion and it all works fine?