Re: [RFC][PATCH] GSoC 2023 proposal: more sparse index integration

[Vivan Garg <v.garg.work@gmail.com>]

> Please wrap your text to 72 (or up to 80) characters; doing that will make
> this much easier for reviewers to format their emails. I've re-wrapped lines
> I'm commenting on below.

I wrote it in Word, copied and pasted it, and then sent it to the mailing list.
However, I will send a revised version that is properly formatted.

> References to other sources (e.g. web links) are usually made with [<N>]
> footnotes. In this case, that might look something like:
>
> "
> Git 2.25.0 introduced a new experimental `git sparse-checkout` command,
> which simplified the existing feature and improved performance for large
> repositories. It allows users to restrict their working directory to only
> the files they care about, allowing them to ensure the developer workflow is
> as fast as possible while maintaining all the benefits of a monorepo. [1]
>
> [1]: https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/
> "
>
> Same goes for the other references you've included.

Actually, I had all of the titles in the word document as hyperlinks;
I'll make this
change for the reviewers on the mailing list, but do you recommend changing it
in the final proposal I'm submitting to Google?

> > +## Microproject
> > +
> > +t4121: modernize test style
> > +Status: ready to merge
>
> To expand on the point made by Ashutosh [1], this microproject is not yet
> tracked by Junio's "What's cooking" emails (most recent here: [2]), so it is
> not "ready to merge." "Under review" would be a more appropriate
> description.
> [1] https://lore.kernel.org/git/CACmM78QTptLOvNHs9oE2NNareSNDb+ydGFKr0VHuboCBWSZbSw@mail.gmail.com/
> [2] https://lore.kernel.org/git/xmqq1qmeyfps.fsf@gitster.g/

I only put that in as a placeholder because the status is likely to change by
the time I submit my proposal. However, I'll change the placeholder to WIP.

>
> > Integration with “mv”
> > Integration with “reset”
> > Integration with “sparse-checkout”
> > Integration with “clean”
> > Integration with “blame”
>
> Please include mailing list archive links to these series.

I also had these as hyperlinks. However, I will include the link here.

> "Two commands per 175 hours" is what I characterized as "rough
> expectations," but the actual number of commands integrated for the project
> will vary based on the complexity of the commands chosen. In a proposal, I
> would expect an applicant present their own, more detailed reasoning around
> how long various parts of the project will take, rather than simply quoting
> my high-level estimate.
> I said that "I'd be willing to extend as far as Oct 2 (four weeks) if
> needed", but that's a general statement about my own availability and does
> not mean that I think such an extension is necessary in this case. The ~360
> hours you mention is too large a margin over the 175 hours allocated for the
> project to properly understand your planned availability. I would prefer a
> more precise breakdown of the time you actually intend to send on the
> project.

Is it sufficient to assign an approximate time I intend to devote to each step
in my plan?

Thanks!