mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <>
To: Atharva Raykar <>
Cc: Kaartic Sivaraam <>,
	git <>,
	Shourya Shukla <>,
	Shourya Shukla <>
Subject: Re: [GSoC][Draft Proposal v2] Finish converting git submodule to builtin
Date: Mon, 12 Apr 2021 15:29:56 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Apr 12, 2021 at 7:56 AM Atharva Raykar <> wrote:
> On 12-Apr-2021, at 01:02, Kaartic Sivaraam <> wrote:
> > On 11/04/21 3:10 pm, Atharva Raykar wrote:

> >> 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 :)

Yeah, the idea is that you should try to show in your proposal that
you have understood some of the problems well enough. If there are
things that are not clear or not very detailed, they are not very
useful as they won't show us that you have understood much. It's
better to focus on a few things or examples and explain them clearly
and with enough detail, than to try to cover a lot of ground in a
vague way.

In other words if you can explain well a sensible plan to convert a
small part of the code, and give sensible details about that small
part, we can have trust that you will manage to do it for the whole
project even if some of the details change.

  reply	other threads:[~2021-04-12 13:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-03 14:08 [GSoC][Draft Proposal] Finish converting git submodule to builtin Atharva Raykar
2021-04-05 16:02 ` Christian Couder
2021-04-08 10:19 ` [GSoC][Draft Proposal v2] " Atharva Raykar
2021-04-10 12:59   ` Christian Couder
2021-04-11  9:40     ` Atharva Raykar
2021-04-11 19:32       ` Kaartic Sivaraam
2021-04-12  5:56         ` Atharva Raykar
2021-04-12 13:29           ` Christian Couder [this message]
2021-04-11 10:17   ` [GSoC][Draft Proposal v3] " Atharva Raykar
2021-05-14 16:00   ` [GSoC][Draft Proposal v2] " Atharva Raykar
2021-05-16 18:40     ` Kaartic Sivaraam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).