ayu-ch <ayu.chandekar@xxxxxxxxx> 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 <ayu.chandekar@xxxxxxxxx> > --- 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.
