> 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@xxxxxxxxxxxxxx/ > [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!
