Thank you so much for your response! I also deeply apologize for the lack of etiquette. I will submit another patch which is the same but follows the guidelines. > Otherwise, the patch looks good. Thanks for the feedback Regards, Ayush On Sat, Feb 1, 2025 at 6:47 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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.
