{"thread":{"id":"62882","subject":"[GSOC] [Newbie] Test Script t6423 Microproject","startedAt":"2025-02-01T00:46:06Z","lastAt":"2025-02-03T16:45:49Z","messageCount":4,"participants":["ayu-ch","Junio C Hamano","Ayush Chandekar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"511611","messageId":"20250201004556.930220-1-ayu.chandekar@gmail.com","threadId":"62882","inReplyTo":null,"subject":"[GSOC] [Newbie] Test Script t6423 Microproject","fromName":"ayu-ch","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-02-01T00:45:56Z","receivedAt":"2025-02-01T00:46:06Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Hello everyone, \nI am Ayush Chandekar, a second-year undergraduate student at IIT Roorkee. \nI've been using Git ever since I started learning about development. When I \nstarted out, I used to solve some problems/exercises related to git. It was \nvery crucial for getting better and now as I'm looking forward to start my \ncontribution to open source, I find Git! I read almost all the docs on the website, blogs \nand tried to understand as much code as I can. I just want to take a moment \nto appreciate how great all the documentation is. It's honestly the best \nI've ever seen out of any org. It developed an urge of giving back to git \nafter I'd spent so much time developing things. I even started a small \nproject of making my own git (obviously mini version). \n\nComing to the topic, I saw that we need to submit a microproject, and I \nstarted to find my microproject. I stumbled upon the thread which mentioned \nskip bitmap traversal for --left-right in git rev-list. I tried to \nunderstand the issue, which I pretty much understood why it's happening, \nbut I figured I still need to discuss it with someone. This is also my \nfirst post/patch on the mailing list, so I would love if someone can discuss \nabout that issue with me :) \n\nThe docs also said that only one microproject should be done, and for now \nI've selected the one mentioned in them, which is Avoid suppressing git's \nexit code in test scripts. But I feel that the ones mentioned are pretty \nsmall. Can I still contribute more by not calling them as microprojects? I \ncan do it for more files, but first I would like to have some feedback about \nmy initial patch. I know there might be a lot of mistakes as this is my \nfirst patch. Thanks for taking out your time for going through this :) \n\nBest regards, \nAyush \n\nSigned-off-by: ayu-ch \n---\n t/t6423-merge-rename-directories.sh | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh\nindex 88d1cf2cde..bdd19de3aa 100755\n--- a/t/t6423-merge-rename-directories.sh\n+++ b/t/t6423-merge-rename-directories.sh\n@@ -5071,7 +5071,7 @@ test_expect_success '12i: Directory rename causes rename-to-self' '\n \t\ttest_path_is_file source/bar &&\n \t\ttest_path_is_file source/baz &&\n \n-\t\tgit ls-files | uniq >tracked &&\n+\t\tgit ls-files >actual && uniq tracked &&\n \t\ttest_line_count = 3 tracked &&\n \n \t\tgit status --porcelain -uno >actual &&\n@@ -5129,7 +5129,7 @@ test_expect_success '12j: Directory rename to root causes rename-to-self' '\n \t\ttest_path_is_file bar &&\n \t\ttest_path_is_file baz &&\n \n-\t\tgit ls-files | uniq >tracked &&\n+\t\tgit ls-files >actual && uniq tracked &&\n \t\ttest_line_count = 3 tracked &&\n \n \t\tgit status --porcelain -uno >actual &&\n@@ -5187,7 +5187,7 @@ test_expect_success '12k: Directory rename with sibling causes rename-to-self' '\n \t\ttest_path_is_file dirA/bar &&\n \t\ttest_path_is_file dirA/baz &&\n \n-\t\tgit ls-files | uniq >tracked &&\n+\t\tgit ls-files >actual && uniq tracked &&\n \t\ttest_line_count = 3 tracked &&\n \n \t\tgit status --porcelain -uno >actual &&\n-- \n2.48.GIT\n\n"},{"id":"511612","messageId":"xmqqjzaa4g6m.fsf@gitster.g","threadId":"62882","inReplyTo":"20250201004556.930220-1-ayu.chandekar@gmail.com","subject":"Re: [GSOC] [Newbie] Test Script t6423 Microproject","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-01T01:17:05Z","receivedAt":"2025-02-01T01:17:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ayu-ch writes:\n\n> Hello everyone, \n> I am Ayush Chandekar, a second-year undergraduate student at IIT Roorkee. \n> I've been using Git ever since I started learning about development. When I \n> started out, I used to solve some problems/exercises related to git. It was \n> very crucial for getting better and now as I'm looking forward to start my \n> contribution to open source, I find Git! I read almost all the docs on the website, blogs \n> and tried to understand as much code as I can. I just want to take a moment \n> to appreciate how great all the documentation is. It's honestly the best \n> I've ever seen out of any org. It developed an urge of giving back to git \n> after I'd spent so much time developing things. I even started a small \n> project of making my own git (obviously mini version). \n>\n> Coming to the topic, I saw that we need to submit a microproject, and I \n> started to find my microproject. I stumbled upon the thread which mentioned \n> skip bitmap traversal for --left-right in git rev-list. I tried to \n> understand the issue, which I pretty much understood why it's happening, \n> but I figured I still need to discuss it with someone. This is also my \n> first post/patch on the mailing list, so I would love if someone can discuss \n> about that issue with me :) \n>\n> The docs also said that only one microproject should be done, and for now \n> I've selected the one mentioned in them, which is Avoid suppressing git's \n> exit code in test scripts. But I feel that the ones mentioned are pretty \n> small. Can I still contribute more by not calling them as microprojects? I \n> can do it for more files, but first I would like to have some feedback about \n> my initial patch. I know there might be a lot of mistakes as this is my \n> first patch. Thanks for taking out your time for going through this :) \n>\n> Best regards, \n> Ayush \n\nWelcome.\n\nThe why our \"microprojects\" are designed to be technically too\ntrivial is because we want to get the formality and the process\nbehind as early as possible. If you look at the output of \"git log\n--no-merges -200\" (and the equivalent \"git shortlog\") from our\nrecent past, you may notice that a contributor must adopt certain\ndiscipline in writing commits for this project, including but not\nlimited to:\n\n - to be familiar with and adhere to the coding guidelines;\n\n - to choose the right granularity to make commits;\n\n - to write the proposed commit log message clearly and in the same\n style as existing commits;\n\n - other formalities like signing off your patches.\n\nIt is expected that a microproject submission would never be perfect\nin the first attempt. Do not let it discourage you if you received\nreview comments that point out the differences between what you did\nin your microproject submission and what we expect to see in our\npatches. During the \"send patches -> get review comments -> send\nupdated patches -> ...\" cycle, you'll learn the proper interaction\nwith the reviewers to get your patches accepted. For that, as an\nexercise material, microprojects are designed to be technically not\ntoo challenging.\n\nThe idea behind \"only one microproject per student\" is that you do\nnot have to do (and we do not want you to deplete our stash of)\nmicroprojects in order to call yourself prepared for one of our\nmentorship programs, like GSoC or Outreachy.\n\nNow, a patch critique.\n\n * Everything you wrote in the body of the message so far are *not*\n suitable for a proposed commit log message. Making introduction\n and stuff is a very good thing to do but that is not something\n you want the \"git am\", which gets run on the receiving end, to\n make it a part of our history (and by the way, you should try\n sending your patch message to yourself and then try to apply it\n with \"git am\" as a practice). Studying \"git log --no-merges\" and\n \"git shortlog --no-merges\" of our history would have taught that\n already.\n\n * The Subject: line which is the patch title needs to be carefully\n written, too. Again, \"git shortlog --no-merges\" would be a good\n guide. We want to make it possible to remind ourselves what each\n commit was about only by looking at the single-line entry in\n \"shortlog\". Your title tells us the commit touches t6423, was\n done by a Newbie, for a GSoC application, as a microproject.\n Among these, the _ONLY_ relevant information in the longer span\n for the project is that it touched t6423. What kind of thing the\n commit did to t6423 is a lot more important than who did that or\n it was done in preparation for GSoC, but the title does not tell\n us that.\n\n * Be familiar with Documentation/SubmittingPatches, as it should\n tell everything I said above, and more, I think. Pay attention\n to the [[real-name]] section, too.\n\n> Signed-off-by: ayu-ch \n> ---\n\nHere, between \"---\" line and the diffstat, is a space you can use to\ngive your \"greetings\", and other things you do not want \"git am\" to\nmake a part of the resulting commit log message. We often use the\nspace to describe what changed since the initial revision when\nsending an updated patch.\n\n> t/t6423-merge-rename-directories.sh | 6 +++---\n> 1 file changed, 3 insertions(+), 3 deletions(-)\n>\n> diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh\n> index 88d1cf2cde..bdd19de3aa 100755\n> --- a/t/t6423-merge-rename-directories.sh\n> +++ b/t/t6423-merge-rename-directories.sh\n> @@ -5071,7 +5071,7 @@ test_expect_success '12i: Directory rename causes rename-to-self' '\n> \t\ttest_path_is_file source/bar &&\n> \t\ttest_path_is_file source/baz &&\n> \n> -\t\tgit ls-files | uniq >tracked &&\n> +\t\tgit ls-files >actual && uniq tracked &&\n> \t\ttest_line_count = 3 tracked &&\n\nWe tend to write one command invocation per line in our shell\nscripts (cf. Documentation/CodingGuidelines), so this should be\nwritten more like:\n\n\t\tgit ls-files >actual &&\n\t\tuniq tracked &&\n\nThe same comment applies to all other hunks.\n\nOtherwise, the patch looks good.\n"},{"id":"511650","messageId":"CAE7as+YC-u84ef=LRP-FB_0ApJbaP6Le6k6QrV58itiGMHsk1Q@mail.gmail.com","threadId":"62882","inReplyTo":"xmqqjzaa4g6m.fsf@gitster.g","subject":"Re: [GSOC] [Newbie] Test Script t6423 Microproject","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-02-02T00:53:41Z","receivedAt":"2025-02-02T00:53:53Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Thank you so much for your response!\nI also deeply apologize for the lack of etiquette. I will submit another patch\nwhich is the same but follows the guidelines.\n\n> Otherwise, the patch looks good.\nThanks for the feedback\n\nRegards,\nAyush\n\nOn Sat, Feb 1, 2025 at 6:47 AM Junio C Hamano wrote:\n>\n> ayu-ch writes:\n>\n> > Hello everyone,\n> > I am Ayush Chandekar, a second-year undergraduate student at IIT Roorkee.\n> > I've been using Git ever since I started learning about development. When I\n> > started out, I used to solve some problems/exercises related to git. It was\n> > very crucial for getting better and now as I'm looking forward to start my\n> > contribution to open source, I find Git! I read almost all the docs on the website, blogs\n> > and tried to understand as much code as I can. I just want to take a moment\n> > to appreciate how great all the documentation is. It's honestly the best\n> > I've ever seen out of any org. It developed an urge of giving back to git\n> > after I'd spent so much time developing things. I even started a small\n> > project of making my own git (obviously mini version).\n> >\n> > Coming to the topic, I saw that we need to submit a microproject, and I\n> > started to find my microproject. I stumbled upon the thread which mentioned\n> > skip bitmap traversal for --left-right in git rev-list. I tried to\n> > understand the issue, which I pretty much understood why it's happening,\n> > but I figured I still need to discuss it with someone. This is also my\n> > first post/patch on the mailing list, so I would love if someone can discuss\n> > about that issue with me :)\n> >\n> > The docs also said that only one microproject should be done, and for now\n> > I've selected the one mentioned in them, which is Avoid suppressing git's\n> > exit code in test scripts. But I feel that the ones mentioned are pretty\n> > small. Can I still contribute more by not calling them as microprojects? I\n> > can do it for more files, but first I would like to have some feedback about\n> > my initial patch. I know there might be a lot of mistakes as this is my\n> > first patch. Thanks for taking out your time for going through this :)\n> >\n> > Best regards,\n> > Ayush\n>\n> Welcome.\n>\n> The why our \"microprojects\" are designed to be technically too\n> trivial is because we want to get the formality and the process\n> behind as early as possible. If you look at the output of \"git log\n> --no-merges -200\" (and the equivalent \"git shortlog\") from our\n> recent past, you may notice that a contributor must adopt certain\n> discipline in writing commits for this project, including but not\n> limited to:\n>\n> - to be familiar with and adhere to the coding guidelines;\n>\n> - to choose the right granularity to make commits;\n>\n> - to write the proposed commit log message clearly and in the same\n> style as existing commits;\n>\n> - other formalities like signing off your patches.\n>\n> It is expected that a microproject submission would never be perfect\n> in the first attempt. Do not let it discourage you if you received\n> review comments that point out the differences between what you did\n> in your microproject submission and what we expect to see in our\n> patches. During the \"send patches -> get review comments -> send\n> updated patches -> ...\" cycle, you'll learn the proper interaction\n> with the reviewers to get your patches accepted. For that, as an\n> exercise material, microprojects are designed to be technically not\n> too challenging.\n>\n> The idea behind \"only one microproject per student\" is that you do\n> not have to do (and we do not want you to deplete our stash of)\n> microprojects in order to call yourself prepared for one of our\n> mentorship programs, like GSoC or Outreachy.\n>\n> Now, a patch critique.\n>\n> * Everything you wrote in the body of the message so far are *not*\n> suitable for a proposed commit log message. Making introduction\n> and stuff is a very good thing to do but that is not something\n> you want the \"git am\", which gets run on the receiving end, to\n> make it a part of our history (and by the way, you should try\n> sending your patch message to yourself and then try to apply it\n> with \"git am\" as a practice). Studying \"git log --no-merges\" and\n> \"git shortlog --no-merges\" of our history would have taught that\n> already.\n>\n> * The Subject: line which is the patch title needs to be carefully\n> written, too. Again, \"git shortlog --no-merges\" would be a good\n> guide. We want to make it possible to remind ourselves what each\n> commit was about only by looking at the single-line entry in\n> \"shortlog\". Your title tells us the commit touches t6423, was\n> done by a Newbie, for a GSoC application, as a microproject.\n> Among these, the _ONLY_ relevant information in the longer span\n> for the project is that it touched t6423. What kind of thing the\n> commit did to t6423 is a lot more important than who did that or\n> it was done in preparation for GSoC, but the title does not tell\n> us that.\n>\n> * Be familiar with Documentation/SubmittingPatches, as it should\n> tell everything I said above, and more, I think. Pay attention\n> to the [[real-name]] section, too.\n>\n> > Signed-off-by: ayu-ch \n> > ---\n>\n> Here, between \"---\" line and the diffstat, is a space you can use to\n> give your \"greetings\", and other things you do not want \"git am\" to\n> make a part of the resulting commit log message. We often use the\n> space to describe what changed since the initial revision when\n> sending an updated patch.\n>\n> > t/t6423-merge-rename-directories.sh | 6 +++---\n> > 1 file changed, 3 insertions(+), 3 deletions(-)\n> >\n> > diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh\n> > index 88d1cf2cde..bdd19de3aa 100755\n> > --- a/t/t6423-merge-rename-directories.sh\n> > +++ b/t/t6423-merge-rename-directories.sh\n> > @@ -5071,7 +5071,7 @@ test_expect_success '12i: Directory rename causes rename-to-self' '\n> > test_path_is_file source/bar &&\n> > test_path_is_file source/baz &&\n> >\n> > - git ls-files | uniq >tracked &&\n> > + git ls-files >actual && uniq tracked &&\n> > test_line_count = 3 tracked &&\n>\n> We tend to write one command invocation per line in our shell\n> scripts (cf. Documentation/CodingGuidelines), so this should be\n> written more like:\n>\n> git ls-files >actual &&\n> uniq tracked &&\n>\n> The same comment applies to all other hunks.\n>\n> Otherwise, the patch looks good.\n"},{"id":"511747","messageId":"xmqqldun2czo.fsf@gitster.g","threadId":"62882","inReplyTo":"CAE7as+YC-u84ef=LRP-FB_0ApJbaP6Le6k6QrV58itiGMHsk1Q@mail.gmail.com","subject":"Re: [GSOC] [Newbie] Test Script t6423 Microproject","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-03T16:45:47Z","receivedAt":"2025-02-03T16:45:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ayush Chandekar writes:\n\n> Thank you so much for your response!\n> I also deeply apologize for the lack of etiquette. I will submit another patch\n> which is the same but follows the guidelines.\n\nNothing to apologize for, and I certainly did not see any lack of\nnetiquette. Each community has its peculiar procedure, and the\nmicroproject time is an opportunity for both sides, i.e. the\nestablished members of the community and the newcomers, to meet in\nthe middle and learn to work together better.\n\nThanks.\n"}]}