Re: [GSoC][Draft Proposal v2] Finish converting git submodule to builtin

> >> The example I gave for how to handle the presence of the remote flag
> >> and the function that performs the module updation method (ie, the `case`
> >> on line 611) was just to illustrate the above workflow, rather than say
> >> that this is how I will exactly do it.
> >> I also would like to know what level of granularity is ideal for the
> >> proposal. For now I have tried to keep it at "whatever I will surely
> >> follow through when I work on the project", which at the moment is the
> >> covered by the four points I mentioned above.
> >> If I go too much into detail about the functions and arguments
> >> of every helper in my example, I will feel compelled to do the same for
> >> the `git submodule add` example. I also will have to reason more carefully
> >> because I do not want to end up in a situation where I do not actually
> >> stick to my proposal all that much, because I realise in my investigation
> >> phase that there is a different, much better way.
> >> Do let me know what is preferred.
> >
> > It makes sense that you don't want to go into too much detail in your
> > proposal. I think Christian wasn't expecting it either. As far as I
> > understand, he was just trying to make your proposal clear to the person
> > who reads it. Just mentioning something like,
> >
> >  This would perform the work being done by the shell script past the
> >  flags being parsed and make the necessary call to `update_clone()',
> >  which returns information about the cloned modules.
> >
> > is not clear as it doesn't say how you're "thinking" the function would
> > return information. Mention this would be helpful for the reader to know
> > what your expectations are and if they need any correction. So, it is
> > better to mention such related information to make your proposal
> > complete. The high-level flow looks good to me.
>
> Alright, I get what you mean. I hope my v3 communicated my intention
> more clearly. Translating my thoughts to text is hard work, and the
> good part of revisiting my proposal and fleshing out the details is
> it is forcing me to understand the problem better :)