RFC][Feature] submodule: teach subcommand 'summary' to give summary for nested submodules

RFC][Feature] submodule: teach subcommand 'summary' to give summary for nested submodules

[Shourya Shukla]

Hello everyone,

I was converting the subcommand 'summary'(of command submodule) from shell to C and I realised that
the subcommand does not have a '--recursive' option in it, meaning it cannot give out summaries of nested
submodules. My opinion on this is that an option should maybe exist for the same.

What are the community's thoughts on this? Should the aforementioned option be added? Is there any feasibility
of this option in this case?

Regards,
Shourya Shukla

Re: [RFC][Feature] submodule: teach subcommand 'summary' to give summary for nested submodules

[Junio C Hamano]

Shourya Shukla <shouryashukla.oo@gmail.com> writes:

> I was converting the subcommand 'summary'(of command submodule)
> from shell to C and I realised that the subcommand does not have a
> '--recursive' option in it, meaning it cannot give out summaries
> of nested submodules. My opinion on this is that an option should
> maybe exist for the same.
>
> What are the community's thoughts on this? Should the
> aforementioned option be added? Is there any feasibility of this
> option in this case?

If "git submodule summary --recursive" errors out with today's code,
no sane user would be using it for any useful purpose, so I would
think it is OK to add such a feature.

If it makes a usable UI for large projects that you can only choose
between "include no subsubmodules" (i.e. with --no-recursive) or
"include all sub(sub)*modules" (i.e. with --recursive) is another
matter, though.

Re: Re: RFC][Feature] submodule

[Shourya Shukla]

Hello Junio,

> If "git submodule summary --recursive" errors out with today's code,
> no sane user would be using it for any useful purpose, so I would
> think it is OK to add such a feature.

Sure thing! I will try to plan some makeshift implementation.

> If it makes a usable UI for large projects that you can only choose
> between "include no subsubmodules" (i.e. with --no-recursive) or
> "include all sub(sub)*modules" (i.e. with --recursive) is another
> matter, though.

I think discussing this idea may be a good approach right now? What
you are saying for large projects does provoke thought though..
Also, what do you think may become a problem for large projects in
here?

Thank you so much for the feedback BTW :)

Regards,
Shourya Shukla

Re: RFC][Feature] submodule

[Junio C Hamano]

Shourya Shukla <shouryashukla.oo@gmail.com> writes:

> Also, what do you think may become a problem for large projects in
> here?

Perhaps

    "We want submodule A and B's sub(sub)*modules all the way down
    to the leaf submodule, but directory C houses many submodules,
    among which only one can be active, and we want C/X and its
    sub(sub)*modules all the way down to the leaf but not C/Y nor
    C/Z or any other C/<anything>."

and similar requests along the line.

Re: Re: [RFC][Feature]

[Shourya Shukla]

>    "We want submodule A and B's sub(sub)*modules all the way down
>    to the leaf submodule, but directory C houses many submodules,
>    among which only one can be active, and we want C/X and its
>    sub(sub)*modules all the way down to the leaf but not C/Y nor
>    C/Z or any other C/<anything>."

That's a tough one. Would you advise developing the feature which may
work atleast for the "normal" cases? In case it does not work for the
aforementioned case and the like, we classify it as a BUG for further
correction?

Regards,
Shourya Shukla

Re: Re: [RFC][Feature]

[Christian Couder]

On Fri, Mar 20, 2020 at 5:08 PM Shourya Shukla
<shouryashukla.oo@gmail.com> wrote:
>
> >    "We want submodule A and B's sub(sub)*modules all the way down
> >    to the leaf submodule, but directory C houses many submodules,
> >    among which only one can be active, and we want C/X and its
> >    sub(sub)*modules all the way down to the leaf but not C/Y nor
> >    C/Z or any other C/<anything>."
>
> That's a tough one. Would you advise developing the feature which may
> work atleast for the "normal" cases? In case it does not work for the
> aforementioned case and the like, we classify it as a BUG for further
> correction?

How are the other git-submodule sub-commands working with --recursive?
Shouldn't --recursive work in the same way for all the sub-commands?

Re: [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>

[Kaartic Sivaraam]

On 19-03-2020 22:12, Shourya Shukla wrote:
> Hello Harshit,
> 
>> Replace 'test -f' with the helper function 'test_path_is_file' as the helper function improves the code readability and also gives better error messages.
> 
> Again the same thing, you may follow what I stated before regarding commit messages.
> 
> The commit title can be of the form:
> 
> t4131: use helpers to replace test -f <path>
> 
> <<commit description>>
> 

Just curious, isn't the commit title already like that in this patch? 
The subject does read:

   [GSoC][PATCH 2/2] t4131: use helper function to replace test -f <path>"

What am I missing?

-- 
Sivaraam

Re: Re: RFC][Feature] submodule

[Shourya Shukla]

Hello Kaartic,

Apologies, I totally missed out on that.

Regards,
Shourya Shukla