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

ayu-ch <ayu.chandekar@gmail.com> writes:

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.

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.

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.