Subject: Re: [GSOC] [Newbie] Test Script t6423 Microproject

From: Junio C Hamano <[email-masked]>
Date: Fri, 31 Jan 2025 17:17:05 -0800

ayu-ch <[email-masked]> writes:

> Hello everyone,  
> I am Ayush Chandekar, a second-year undergraduate student at IIT Roorkee.  
> I've been using Git ever since I started learning about development. When I  
> started out, I used to solve some problems/exercises related to git. It was  
> very crucial for getting better and now as I'm looking forward to start my  
> contribution to open source, I find Git! I read almost all the docs on the website, blogs  
> and tried to understand as much code as I can. I just want to take a moment  
> to appreciate how great all the documentation is. It's honestly the best  
> I've ever seen out of any org. It developed an urge of giving back to git  
> after I'd spent so much time developing things. I even started a small  
> project of making my own git (obviously mini version).  
>
> Coming to the topic, I saw that we need to submit a microproject, and I  
> started to find my microproject. I stumbled upon the thread which mentioned  
> skip bitmap traversal for --left-right in git rev-list. I tried to  
> understand the issue, which I pretty much understood why it's happening,  
> but I figured I still need to discuss it with someone. This is also my  
> first post/patch on the mailing list, so I would love if someone can discuss  
> about that issue with me :)  
>
> The docs also said that only one microproject should be done, and for now  
> I've selected the one mentioned in them, which is Avoid suppressing git's  
> exit code in test scripts. But I feel that the ones mentioned are pretty  
> small. Can I still contribute more by not calling them as microprojects? I  
> can do it for more files, but first I would like to have some feedback about  
> my initial patch. I know there might be a lot of mistakes as this is my  
> first patch. Thanks for taking out your time for going through this :)  
>
> Best regards,  
> Ayush  

Welcome.

The why our "microprojects" are designed to be technically too
trivial is because we want to get the formality and the process
behind as early as possible.  If you look at the output of "git log
--no-merges -200" (and the equivalent "git shortlog") from our
recent past, you may notice that a contributor must adopt certain
discipline in writing commits for this project, including but not
limited to:

 - to be familiar with and adhere to the coding guidelines;

 - to choose the right granularity to make commits;

 - to write the proposed commit log message clearly and in the same
   style as existing commits;

 - other formalities like signing off your patches.

It is expected that a microproject submission would never be perfect
in the first attempt.  Do not let it discourage you if you received
review comments that point out the differences between what you did
in your microproject submission and what we expect to see in our
patches.  During the "send patches -> get review comments -> send
updated patches -> ..." cycle, you'll learn the proper interaction
with the reviewers to get your patches accepted.  For that, as an
exercise material, microprojects are designed to be technically not
too challenging.

The idea behind "only one microproject per student" is that you do
not have to do (and we do not want you to deplete our stash of)
microprojects in order to call yourself prepared for one of our
mentorship programs, like GSoC or Outreachy.

Now, a patch critique.

 * Everything you wrote in the body of the message so far are *not*
   suitable for a proposed commit log message.  Making introduction
   and stuff is a very good thing to do but that is not something
   you want the "git am", which gets run on the receiving end, to
   make it a part of our history (and by the way, you should try
   sending your patch message to yourself and then try to apply it
   with "git am" as a practice).  Studying "git log --no-merges" and
   "git shortlog --no-merges" of our history would have taught that
   already.

 * The Subject: line which is the patch title needs to be carefully
   written, too.  Again, "git shortlog --no-merges" would be a good
   guide.  We want to make it possible to remind ourselves what each
   commit was about only by looking at the single-line entry in
   "shortlog".  Your title tells us the commit touches t6423, was
   done by a Newbie, for a GSoC application, as a microproject.
   Among these, the _ONLY_ relevant information in the longer span
   for the project is that it touched t6423.  What kind of thing the
   commit did to t6423 is a lot more important than who did that or
   it was done in preparation for GSoC, but the title does not tell
   us that.

 * Be familiar with Documentation/SubmittingPatches, as it should
   tell everything I said above, and more, I think.  Pay attention
   to the [[real-name]] section, too.

> Signed-off-by: ayu-ch <[email-masked]>
> ---

Here, between "---" line and the diffstat, is a space you can use to
give your "greetings", and other things you do not want "git am" to
make a part of the resulting commit log message.  We often use the
space to describe what changed since the initial revision when
sending an updated patch.

>  t/t6423-merge-rename-directories.sh | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh
> index 88d1cf2cde..bdd19de3aa 100755
> --- a/t/t6423-merge-rename-directories.sh
> +++ b/t/t6423-merge-rename-directories.sh
> @@ -5071,7 +5071,7 @@ test_expect_success '12i: Directory rename causes rename-to-self' '
>  		test_path_is_file source/bar &&
>  		test_path_is_file source/baz &&
>  
> -		git ls-files | uniq >tracked &&
> +		git ls-files >actual && uniq <actual >tracked &&
>  		test_line_count = 3 tracked &&

We tend to write one command invocation per line in our shell
scripts (cf. Documentation/CodingGuidelines), so this should be
written more like:

		git ls-files >actual &&
		uniq <actual >tracked &&

The same comment applies to all other hunks.

Otherwise, the patch looks good.