On Mon, Jul 31, 2017 at 1:56 PM, Prathamesh Chavan <pc44800@xxxxxxxxx> 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@xxxxxxxxx> > Mentored-by: Stefan Beller <sbeller@xxxxxxxxxx> > Signed-off-by: Prathamesh Chavan <pc44800@xxxxxxxxx> > --- > 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? I have reviewed the patches up to (and including this) patch and so far they look good to me. Thanks, Stefan
