Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[Junio C Hamano <gitster@pobox.com>]

Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:

> A
> microproject is something simpler than that. See the microprojects
> page [1] for suggestions. They are more straightforward things that
> have more chances of being accepted quickly. And since having an accepted
> microproject is a mandatory step, you'll probably want it to be merged
> as soon as possible.

Microproject is to serve as a practice session for a new contributor
to go through the patch submission + getting reviewed + sending
polished version cycle.  It does not have to result in a merge to
the project, but it is essential to get reviewed and respond to
reviews.  How well you work with reviewers is the focus of the
observation, and how complex the problem you tackle is is of much
lessor importance.

> I think that this seems to be easy to do, but the reviewing process
> may take some time, so it would be better if you stick to a
> one of the selected microprojects [1].
>
> [1] https://git.github.io/SoC-2024-Microprojects/

Is https://git.github.io/SoC-2026-Microprojects/ the latest?  The
above URL points at one a few years old.

Anyway, this list however might want a bit of updating.

 * I personally feel that "run_command*() to internal call" is way
   too involved for a microproject.  All the low-hanging frutis have
   already been picked in this area, I think.  That is why this does
   not appear in the list of microproject ideas in more recent
   years.

 * People seem to be finding more instances of "test -X" to replace
   with test_path_is_* helpers, so that would be fine to keep for
   now.

 * Ditto for "do not place git upstream of a pipe".

 * "Do not use signed int for collection of flag bits" may have
   outlived its usefulness, as it seems we are pushing more and more
   uses of enum for collection of flag bits.