{"thread":{"id":"63079","subject":"[GSoC] Microproject: Updating Documentation","startedAt":"2025-03-08T15:41:42Z","lastAt":"2025-03-12T08:19:19Z","messageCount":7,"participants":["JAYATHEERTH K","Mahendra Dani","Junio C Hamano","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"513830","messageId":"CA+rGoLc69R8qgbkYQiKoc2uweDwD10mxZXYFSY8xFs5eKSRVkA@mail.gmail.com","threadId":"63079","inReplyTo":null,"subject":"[GSoC] Microproject: Updating Documentation","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2025-03-08T15:41:30Z","receivedAt":"2025-03-08T15:41:42Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hey Git community, I'm Jayatheerth (he/him) you can call me Jay.\n\nI'm pretty new to open source and since I know C, Python, Rust and\nShell scripting and experience with Git, I wanted to contribute to Git\nitself.\nI always wanted to contribute to open source code as I use them on a\ndaily basis and I would love to stay even after GSOC...\n\nSo I had a question. I went through the documentation in Git source\ncode as I'm new to Git and I found that there were several outdated\nelements and issues.\n\nSince Git suggests starting with a small microproject I wanted to ask\nfor advice if updating MyFirstContribution.adoc would be a good micro\nproject or am I looking in the wrong way?\n\nThank you,\nJay\n"},{"id":"513833","messageId":"CABGrwBDLO9=FCjUW_LfJ_RZ95bRXWHFFNvdJfOuiYocGXdj3Mg@mail.gmail.com","threadId":"63079","inReplyTo":"CA+rGoLc69R8qgbkYQiKoc2uweDwD10mxZXYFSY8xFs5eKSRVkA@mail.gmail.com","subject":"Re: [GSoC] Microproject: Updating Documentation","fromName":"Mahendra Dani","fromEmail":"danimahendra0904@gmail.com","sentAt":"2025-03-08T17:33:45Z","receivedAt":"2025-03-08T17:33:58Z","isPatch":false,"sender":{"key":"danimahendra0904@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116940083?v=4"},"body":"On Sat, Mar 8, 2025 at 9:11 PM JAYATHEERTH K\n wrote:\n>\n> Hey Git community, I'm Jayatheerth (he/him) you can call me Jay.\n>\nHi Jay!\n\n> I'm pretty new to open source and since I know C, Python, Rust and\n> Shell scripting and experience with Git, I wanted to contribute to Git\n> itself.\n> I always wanted to contribute to open source code as I use them on a\n> daily basis and I would love to stay even after GSOC...\n>\nThat's amazing.\n\n> So I had a question. I went through the documentation in Git source\n> code as I'm new to Git and I found that there were several outdated\n> elements and issues.\n>\nOk. Can you provide references to the issues?\n\n> Since Git suggests starting with a small microproject I wanted to ask\n> for advice if updating MyFirstContribution.adoc would be a good micro\n> project or am I looking in the wrong way?\n>\nI'd suggest trying to submit a microproject listed in [1]. Further,\nplease go through the General Microproject Information[2] and\nMyFirstContribution[3].\n\n> Thank you,\n> Jay\n>\n\n[[ References ]]\n1. https://git.github.io/SoC-2025-Microprojects/\n2. https://git.github.io/General-Microproject-Information/\n3. https://git-scm.com/docs/MyFirstContribution\n\nThanks,\nMahendra.\n"},{"id":"513834","messageId":"xmqqo6ybb48p.fsf@gitster.g","threadId":"63079","inReplyTo":"CABGrwBDLO9=FCjUW_LfJ_RZ95bRXWHFFNvdJfOuiYocGXdj3Mg@mail.gmail.com","subject":"Re: [GSoC] Microproject: Updating Documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-08T21:29:42Z","receivedAt":"2025-03-08T21:29:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mahendra Dani writes:\n\n> I'd suggest trying to submit a microproject listed in [1]. Further,\n> please go through the General Microproject Information[2] and\n> MyFirstContribution[3].\n\nAll good suggestions, but we also welcome students who try to\nscratch their own itch, as long as it is small enough to be suitable\nas a microproject material. And it is fine to ask if doing X\nqualifies as a microproject or if it is too involved.\n\nThe primary objective for a micro-project is to get used to the\nworkflow, i.e. working with the community mainly via this mailing\nlist, how you explain your changes in your proposed commit log\nmessage, how to work with those who gave you reviews, how your\nupdated submission should look like, etc., etc. Given that, it is\nrare that anything is too trivial as a microproject material, but\nyou would not want to choose something too involved, as it would\nslow you down in learning the procedure, which is the main focus on\nthe microproject period.\n\nAnother thing I noticed in the original message that is worth\nreacting is that you do not need to ask for permission to start\nworking on anything around here. \"Am I allowed to do X for my\nmicroproject\" is not the question you want to ask; rather \"I see\ndocument X says A, B, and C, but A is outdated and I think it is\nbetter to phrase it like D. Would it be a suitable microproject\nmaterial?\" is something we can work with. Answers may depend on the\nnature of A, B, C, and D and would range from \"nah, A is fine and D\nis not better because ...; don't do it\" to \"great, yes A may have\nbeen suitable a decade ago, but no longer relevant, and D would be a\ngreat addition\", to \"Yeah, I agree that A is not great, but D is not\nall that better, how about E?\", to \"Yes that is a great suggestion,\nbut wouldn't it may be a bit too much as a microproject\".\n\nTo solicit such productive reaction from others, you'd need to be a\nbit more specific than \"I see flaws and want to improve\".\n\nThanks, and good luck with your microproject selection.\n"},{"id":"513846","messageId":"CA+rGoLfTJSHQZTvNBgfcMmGjJwqak+wGHh9PRhHfqHSxB2p6-g@mail.gmail.com","threadId":"63079","inReplyTo":"xmqqo6ybb48p.fsf@gitster.g","subject":"Re: [GSoC] Microproject: Updating Documentation","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2025-03-09T09:59:11Z","receivedAt":"2025-03-09T09:59:24Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hey Junio and Mahendra, Thanks for your responses, they’ve been super\nhelpful in guiding me as a new contributor!\n\nOn Sun, Mar 9, 2025 at 2:59 AM Junio C Hamano wrote:\n>\n> Mahendra Dani writes:\n>\n> > I'd suggest trying to submit a microproject listed in [1]. Further,\n> > please go through the General Microproject Information[2] and\n> > MyFirstContribution[3].\n>\n\nI've gone through the links posted by Mahendra and read the micro\nprojects list too.\nI've also explored that we as students can have our own idea as long\nas it doesn't get too involved.\nThese emails actually cleared up a lot about how microprojects are evaluated\n\n> All good suggestions, but we also welcome students who try to\n> scratch their own itch, as long as it is small enough to be suitable\n> as a microproject material. And it is fine to ask if doing X\n> qualifies as a microproject or if it is too involved.\n>\n> The primary objective for a micro-project is to get used to the\n> workflow, i.e. working with the community mainly via this mailing\n> list, how you explain your changes in your proposed commit log\n> message, how to work with those who gave you reviews, how your\n> updated submission should look like, etc., etc. Given that, it is\n> rare that anything is too trivial as a microproject material, but\n> you would not want to choose something too involved, as it would\n> slow you down in learning the procedure, which is the main focus on\n> the microproject period.\n>\n\nThis really helps set expectations as learning the workflow is my main\ngoal here, so I’ve picked small fixes that I think will help me get\nfamiliar with the process.\n\n> Another thing I noticed in the original message that is worth\n> reacting is that you do not need to ask for permission to start\n> working on anything around here. \"Am I allowed to do X for my\n> microproject\" is not the question you want to ask; rather \"I see\n> document X says A, B, and C, but A is outdated and I think it is\n> better to phrase it like D. Would it be a suitable microproject\n> material?\" is something we can work with. Answers may depend on the\n> nature of A, B, C, and D and would range from \"nah, A is fine and D\n> is not better because ...; don't do it\" to \"great, yes A may have\n> been suitable a decade ago, but no longer relevant, and D would be a\n> great addition\", to \"Yeah, I agree that A is not great, but D is not\n> all that better, how about E?\", to \"Yes that is a great suggestion,\n> but wouldn't it may be a bit too much as a microproject\".\n>\n\nGot it, I’ll focus on being specific about what I see and what I’d change.\nHere’s what I found in \"MyFirstContribution.adoc\" and \"config.h\" my\nproposed fixes:\n\n1. Outdated Function Signature in Documentation In the \"Adding a New\nCommand\" section\n(https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#adding-a-new-command),\nthe signature for cmd_psuh() is:\nint cmd_psuh(int argc, const char **argv, const char *prefix);\nBut the current Git codebase (builtin.h) expects:\nint cmd_psuh(int argc, const char **argv, const char *prefix, struct\nrepository *repo);\nThis mismatch caused compilation errors when I tried following the tutorial.\nProposed Fix: Update the signature in the doc to include struct\nrepository *repo.\n\n2. Unused Parameters Handling Not Documented The tutorial code doesn’t\nmention that unused parameters (argc, argv, etc.) will trigger\ncompiler warnings. The current Git codebase uses the UNUSED macro\n(e.g., as seen in cmd_check_ref_format in builtin/check-ref-format.c)\nto handle this, but the doc skips this detail.\nProposed Fix: Add a note in the doc explaining how to use the UNUSED\nmacro for unused arguments, and update the example code snippet to\nreflect this.\n\n3. Incorrect Config Function Reference In the \"Implementation\" section\n(https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#implementation),\nit mentions git_config(...), but config.c doesn’t define it.\nI had to use repo_config(...) instead, which isn’t documented here.\nProposed Fix: Update the doc to use repo_config(...) and explain its usage.\nAdditional Note: I can also edit the config files to appropriately\ncorrect the git_config() function if needed, but I’d require some\nguidance as to not mess up other programs while doing this as I\nbelieve config.c/config.h is used by a lot of other files too.\n\n4. Outdated Reference Link The doc points to a GitHub repo\n(https://github.com/nasamuffin/git/tree/psuh) as a reference\nimplementation,\nbut it’s not updated to the latest Git version, which confused me when\nI tried following it.\nProposed Fix: Update the link to a maintained branch or clarify its status.\n\n\n> To solicit such productive reaction from others, you'd need to be a\n> bit more specific than \"I see flaws and want to improve\".\n>\n\nI seek feedback as to if this mail is well specified or do I need to\nimprove in any parameters.\nI also seek feedback in terms of my understanding with Git workflow\nand also with my understanding with Git codebase. Any feedback will be\ngreat for me.\n\n> Thanks, and good luck with your microproject selection.\n\nThanks again,\nJay\n"},{"id":"513850","messageId":"CA+rGoLfwetxdij9ZLZx7bcxNXfzTi7hRSSkJu+AMhVX6W02v9g@mail.gmail.com","threadId":"63079","inReplyTo":"CA+rGoLfTJSHQZTvNBgfcMmGjJwqak+wGHh9PRhHfqHSxB2p6-g@mail.gmail.com","subject":"Re: [GSoC] Microproject: Updating Documentation","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2025-03-09T14:55:52Z","receivedAt":"2025-03-09T14:56:06Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"> 3. Incorrect Config Function Reference In the \"Implementation\" section\n> (https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#implementation),\n> it mentions git_config(...), but config.c doesn’t define it.\n> I had to use repo_config(...) instead, which isn’t documented here.\n> Proposed Fix: Update the doc to use repo_config(...) and explain its usage.\n> Additional Note: I can also edit the config files to appropriately\n> correct the git_config() function if needed, but I’d require some\n> guidance as to not mess up other programs while doing this as I\n> believe config.c/config.h is used by a lot of other files too.\n>\n\nA small clarification on this I made a small error where I said\ngit_config(...) was not defined, I actually did a grep check and found\nthe wrapper function(#ifdef USE_THE_REPOSITORY_VARIABLE) , here's my\nupdated proposed fix\n\nTo update the MyFirstContribution.adoc to use repo_config as the *repo\nis getting involved with the cmd_psuh. As this would be confusing for\nmany people at the start.\n\nThank you,\nJay\n"},{"id":"513946","messageId":"CAOLa=ZTVOBNMLHE0Wa=vpYdcy56V+S1QdQM1Rk8XWQye32tL0g@mail.gmail.com","threadId":"63079","inReplyTo":"CA+rGoLfTJSHQZTvNBgfcMmGjJwqak+wGHh9PRhHfqHSxB2p6-g@mail.gmail.com","subject":"Re: [GSoC] Microproject: Updating Documentation","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-03-10T21:45:03Z","receivedAt":"2025-03-10T21:45:05Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"JAYATHEERTH K writes:\n\n> Hey Junio and Mahendra, Thanks for your responses, they’ve been super\n> helpful in guiding me as a new contributor!\n>\n> On Sun, Mar 9, 2025 at 2:59 AM Junio C Hamano wrote:\n>>\n>> Mahendra Dani writes:\n>>\n>> > I'd suggest trying to submit a microproject listed in [1]. Further,\n>> > please go through the General Microproject Information[2] and\n>> > MyFirstContribution[3].\n>>\n>\n> I've gone through the links posted by Mahendra and read the micro\n> projects list too.\n> I've also explored that we as students can have our own idea as long\n> as it doesn't get too involved.\n> These emails actually cleared up a lot about how microprojects are evaluated\n>\n>> All good suggestions, but we also welcome students who try to\n>> scratch their own itch, as long as it is small enough to be suitable\n>> as a microproject material. And it is fine to ask if doing X\n>> qualifies as a microproject or if it is too involved.\n>>\n>> The primary objective for a micro-project is to get used to the\n>> workflow, i.e. working with the community mainly via this mailing\n>> list, how you explain your changes in your proposed commit log\n>> message, how to work with those who gave you reviews, how your\n>> updated submission should look like, etc., etc. Given that, it is\n>> rare that anything is too trivial as a microproject material, but\n>> you would not want to choose something too involved, as it would\n>> slow you down in learning the procedure, which is the main focus on\n>> the microproject period.\n>>\n>\n> This really helps set expectations as learning the workflow is my main\n> goal here, so I’ve picked small fixes that I think will help me get\n> familiar with the process.\n>\n>> Another thing I noticed in the original message that is worth\n>> reacting is that you do not need to ask for permission to start\n>> working on anything around here. \"Am I allowed to do X for my\n>> microproject\" is not the question you want to ask; rather \"I see\n>> document X says A, B, and C, but A is outdated and I think it is\n>> better to phrase it like D. Would it be a suitable microproject\n>> material?\" is something we can work with. Answers may depend on the\n>> nature of A, B, C, and D and would range from \"nah, A is fine and D\n>> is not better because ...; don't do it\" to \"great, yes A may have\n>> been suitable a decade ago, but no longer relevant, and D would be a\n>> great addition\", to \"Yeah, I agree that A is not great, but D is not\n>> all that better, how about E?\", to \"Yes that is a great suggestion,\n>> but wouldn't it may be a bit too much as a microproject\".\n>>\n>\n> Got it, I’ll focus on being specific about what I see and what I’d change.\n> Here’s what I found in \"MyFirstContribution.adoc\" and \"config.h\" my\n> proposed fixes:\n>\n> 1. Outdated Function Signature in Documentation In the \"Adding a New\n> Command\" section\n> (https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#adding-a-new-command),\n> the signature for cmd_psuh() is:\n> int cmd_psuh(int argc, const char **argv, const char *prefix);\n> But the current Git codebase (builtin.h) expects:\n> int cmd_psuh(int argc, const char **argv, const char *prefix, struct\n> repository *repo);\n> This mismatch caused compilation errors when I tried following the tutorial.\n> Proposed Fix: Update the signature in the doc to include struct\n> repository *repo.\n>\n\nYes, this would be nice for users who try to follow the guide.\n\n> 2. Unused Parameters Handling Not Documented The tutorial code doesn’t\n> mention that unused parameters (argc, argv, etc.) will trigger\n> compiler warnings. The current Git codebase uses the UNUSED macro\n> (e.g., as seen in cmd_check_ref_format in builtin/check-ref-format.c)\n> to handle this, but the doc skips this detail.\n> Proposed Fix: Add a note in the doc explaining how to use the UNUSED\n> macro for unused arguments, and update the example code snippet to\n> reflect this.\n>\n\nThis seems worthwhile too!\n\n> 3. Incorrect Config Function Reference In the \"Implementation\" section\n> (https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#implementation),\n> it mentions git_config(...), but config.c doesn’t define it.\n> I had to use repo_config(...) instead, which isn’t documented here.\n> Proposed Fix: Update the doc to use repo_config(...) and explain its usage.\n> Additional Note: I can also edit the config files to appropriately\n> correct the git_config() function if needed, but I’d require some\n> guidance as to not mess up other programs while doing this as I\n> believe config.c/config.h is used by a lot of other files too.\n\nI think for new commands and also for new users, it is not worthwhile to\nget into how the `USE_THE_REPOSITORY_VARIABLE` macro works.\n\nSo I think it'd be best to modify the documentation to use\n'repo_config()' as you suggested here.\n\n> 4. Outdated Reference Link The doc points to a GitHub repo\n> (https://github.com/nasamuffin/git/tree/psuh) as a reference\n> implementation,\n> but it’s not updated to the latest Git version, which confused me when\n> I tried following it.\n> Proposed Fix: Update the link to a maintained branch or clarify its status.\n\nThis is a bit hard, since this is linked to an external repository.\nGenerally the code referred to in this document doesn't seldom change,\nso I think the easiest way to update this would be to raise a PR to\nEmily's repository with the update, so the link could stay the same.\nCC'd Emily in this email.\n\nI also see some more potential fixes to the documentation, which you\ncould also overtake (if you wish too :))\n- Remove git-mentoring@googlegroups.com [1].\n- Rename 'Documentation/git-psuh.txt' -> 'Documentation/git-psuh.adoc'.\n\n[1]: https://public-inbox.org/git/CAJoAoZnk88ZFZFdEtUxMnUa1OZiXYOgcw8DSbB+A0LzyCPFugg@mail.gmail.com/\n\n>> To solicit such productive reaction from others, you'd need to be a\n>> bit more specific than \"I see flaws and want to improve\".\n>>\n>\n> I seek feedback as to if this mail is well specified or do I need to\n> improve in any parameters.\n> I also seek feedback in terms of my understanding with Git workflow\n> and also with my understanding with Git codebase. Any feedback will be\n> great for me.\n>\n\nI think the changes you suggested would be great to have. Looking\nforward to the patche[s].\n\n>> Thanks, and good luck with your microproject selection.\n>\n> Thanks again,\n> Jay\n\nThanks for fixing documentation, it is very important to keep them\nupdated!\n\nKarthik\n"},{"id":"514033","messageId":"CA+rGoLdwGfFD0K+DW-XOJEOx6m-BmOg82T1g_y2u5ieD5vVyWw@mail.gmail.com","threadId":"63079","inReplyTo":"CAOLa=ZTVOBNMLHE0Wa=vpYdcy56V+S1QdQM1Rk8XWQye32tL0g@mail.gmail.com","subject":"Re: [GSoC] Microproject: Updating Documentation","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2025-03-12T08:19:07Z","receivedAt":"2025-03-12T08:19:19Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hey Karthik,\n\nI've looked into the mail and have added a PR to Git [1]\nI also sent an email [2] starting a new thread with the patch details.\n\n1 - https://github.com/git/git/pull/1913\n2- https://lore.kernel.org/git/20250312081534.75536-1-jayatheerthkulkarni2005@gmail.com/T/#u\n\nLooking forward to feedback.\n\nThank you,\nJay\n\n\n\nOn Tue, Mar 11, 2025 at 3:15 AM Karthik Nayak wrote:\n>\n> JAYATHEERTH K writes:\n>\n> > Hey Junio and Mahendra, Thanks for your responses, they’ve been super\n> > helpful in guiding me as a new contributor!\n> >\n> > On Sun, Mar 9, 2025 at 2:59 AM Junio C Hamano wrote:\n> >>\n> >> Mahendra Dani writes:\n> >>\n> >> > I'd suggest trying to submit a microproject listed in [1]. Further,\n> >> > please go through the General Microproject Information[2] and\n> >> > MyFirstContribution[3].\n> >>\n> >\n> > I've gone through the links posted by Mahendra and read the micro\n> > projects list too.\n> > I've also explored that we as students can have our own idea as long\n> > as it doesn't get too involved.\n> > These emails actually cleared up a lot about how microprojects are evaluated\n> >\n> >> All good suggestions, but we also welcome students who try to\n> >> scratch their own itch, as long as it is small enough to be suitable\n> >> as a microproject material. And it is fine to ask if doing X\n> >> qualifies as a microproject or if it is too involved.\n> >>\n> >> The primary objective for a micro-project is to get used to the\n> >> workflow, i.e. working with the community mainly via this mailing\n> >> list, how you explain your changes in your proposed commit log\n> >> message, how to work with those who gave you reviews, how your\n> >> updated submission should look like, etc., etc. Given that, it is\n> >> rare that anything is too trivial as a microproject material, but\n> >> you would not want to choose something too involved, as it would\n> >> slow you down in learning the procedure, which is the main focus on\n> >> the microproject period.\n> >>\n> >\n> > This really helps set expectations as learning the workflow is my main\n> > goal here, so I’ve picked small fixes that I think will help me get\n> > familiar with the process.\n> >\n> >> Another thing I noticed in the original message that is worth\n> >> reacting is that you do not need to ask for permission to start\n> >> working on anything around here. \"Am I allowed to do X for my\n> >> microproject\" is not the question you want to ask; rather \"I see\n> >> document X says A, B, and C, but A is outdated and I think it is\n> >> better to phrase it like D. Would it be a suitable microproject\n> >> material?\" is something we can work with. Answers may depend on the\n> >> nature of A, B, C, and D and would range from \"nah, A is fine and D\n> >> is not better because ...; don't do it\" to \"great, yes A may have\n> >> been suitable a decade ago, but no longer relevant, and D would be a\n> >> great addition\", to \"Yeah, I agree that A is not great, but D is not\n> >> all that better, how about E?\", to \"Yes that is a great suggestion,\n> >> but wouldn't it may be a bit too much as a microproject\".\n> >>\n> >\n> > Got it, I’ll focus on being specific about what I see and what I’d change.\n> > Here’s what I found in \"MyFirstContribution.adoc\" and \"config.h\" my\n> > proposed fixes:\n> >\n> > 1. Outdated Function Signature in Documentation In the \"Adding a New\n> > Command\" section\n> > (https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#adding-a-new-command),\n> > the signature for cmd_psuh() is:\n> > int cmd_psuh(int argc, const char **argv, const char *prefix);\n> > But the current Git codebase (builtin.h) expects:\n> > int cmd_psuh(int argc, const char **argv, const char *prefix, struct\n> > repository *repo);\n> > This mismatch caused compilation errors when I tried following the tutorial.\n> > Proposed Fix: Update the signature in the doc to include struct\n> > repository *repo.\n> >\n>\n> Yes, this would be nice for users who try to follow the guide.\n>\n> > 2. Unused Parameters Handling Not Documented The tutorial code doesn’t\n> > mention that unused parameters (argc, argv, etc.) will trigger\n> > compiler warnings. The current Git codebase uses the UNUSED macro\n> > (e.g., as seen in cmd_check_ref_format in builtin/check-ref-format.c)\n> > to handle this, but the doc skips this detail.\n> > Proposed Fix: Add a note in the doc explaining how to use the UNUSED\n> > macro for unused arguments, and update the example code snippet to\n> > reflect this.\n> >\n>\n> This seems worthwhile too!\n>\n> > 3. Incorrect Config Function Reference In the \"Implementation\" section\n> > (https://github.com/git/git/blob/master/Documentation/MyFirstContribution.adoc#implementation),\n> > it mentions git_config(...), but config.c doesn’t define it.\n> > I had to use repo_config(...) instead, which isn’t documented here.\n> > Proposed Fix: Update the doc to use repo_config(...) and explain its usage.\n> > Additional Note: I can also edit the config files to appropriately\n> > correct the git_config() function if needed, but I’d require some\n> > guidance as to not mess up other programs while doing this as I\n> > believe config.c/config.h is used by a lot of other files too.\n>\n> I think for new commands and also for new users, it is not worthwhile to\n> get into how the `USE_THE_REPOSITORY_VARIABLE` macro works.\n>\n> So I think it'd be best to modify the documentation to use\n> 'repo_config()' as you suggested here.\n>\n> > 4. Outdated Reference Link The doc points to a GitHub repo\n> > (https://github.com/nasamuffin/git/tree/psuh) as a reference\n> > implementation,\n> > but it’s not updated to the latest Git version, which confused me when\n> > I tried following it.\n> > Proposed Fix: Update the link to a maintained branch or clarify its status.\n>\n> This is a bit hard, since this is linked to an external repository.\n> Generally the code referred to in this document doesn't seldom change,\n> so I think the easiest way to update this would be to raise a PR to\n> Emily's repository with the update, so the link could stay the same.\n> CC'd Emily in this email.\n>\n> I also see some more potential fixes to the documentation, which you\n> could also overtake (if you wish too :))\n> - Remove git-mentoring@googlegroups.com [1].\n> - Rename 'Documentation/git-psuh.txt' -> 'Documentation/git-psuh.adoc'.\n>\n> [1]: https://public-inbox.org/git/CAJoAoZnk88ZFZFdEtUxMnUa1OZiXYOgcw8DSbB+A0LzyCPFugg@mail.gmail.com/\n>\n> >> To solicit such productive reaction from others, you'd need to be a\n> >> bit more specific than \"I see flaws and want to improve\".\n> >>\n> >\n> > I seek feedback as to if this mail is well specified or do I need to\n> > improve in any parameters.\n> > I also seek feedback in terms of my understanding with Git workflow\n> > and also with my understanding with Git codebase. Any feedback will be\n> > great for me.\n> >\n>\n> I think the changes you suggested would be great to have. Looking\n> forward to the patche[s].\n>\n> >> Thanks, and good luck with your microproject selection.\n> >\n> > Thanks again,\n> > Jay\n>\n> Thanks for fixing documentation, it is very important to keep them\n> updated!\n>\n> Karthik\n"}]}