[GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites

[GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites

[K Jayatheerth]

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index afcf4b46c1..f7e510e6c1 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -13,6 +13,7 @@ the Git tree, sending it for review, and making changes based on comments.
 
 This tutorial assumes you're already fairly familiar with using Git to manage
 source code.  The Git workflow steps will largely remain unexplained.
+This tutorial also assumes you know/understand C programming language in a good capacity.
 
 [[related-reading]]
 === Related Reading
@@ -40,13 +41,6 @@ the list by sending an email to <git+subscribe@vger.kernel.org>
 The https://lore.kernel.org/git[archive] of this mailing list is
 available to view in a browser.
 
-==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]
-
-This mailing list is targeted to new contributors and was created as a place to
-post questions and receive answers outside of the public eye of the main list.
-Veteran contributors who are especially interested in helping mentor newcomers
-are present on the list. In order to avoid search indexers, group membership is
-required to view messages; anyone can join and no approval is required.
 
 ==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat
 
-- 
2.48.1

[GSOC][PATCH 2/3] Update function signature and UNUSED to include struct repository and modify builtin.h accordingly

[K Jayatheerth]

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index f7e510e6c1..34a0336898 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -142,9 +142,13 @@ followed by the name of the subcommand, in a source file named after the
 subcommand and contained within `builtin/`. So it makes sense to implement your
 command in `builtin/psuh.c`. Create that file, and within it, write the entry
 point for your command in a function matching the style and signature:
-
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix)
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
+----
+Before proceeding further, we should use the UNUSED macro to suppress warnings about unused parameters in the function.
+This prevents the compiler from generating warnings when certain parameters are not used within the function body:
+----
+int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
 ----
 
 We'll also need to add the declaration of psuh; open up `builtin.h`, find the
@@ -152,7 +156,7 @@ declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
 in order to keep the declarations alphabetically sorted:
 
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix);
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo);
 ----
 
 Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
@@ -168,7 +172,7 @@ Throughout the tutorial, we will mark strings for translation as necessary; you
 should also do so when writing your user-facing commands in the future.
 
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix)
+int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
 {
 	printf(_("Pony saying hello goes here.\n"));
 	return 0;
@@ -199,6 +203,9 @@ with the command name, a function pointer to the command implementation, and a
 setup option flag. For now, let's keep mimicking `push`. Find the line where
 `cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
 line in alphabetical order (immediately before `cmd_pull`).
+----
+{ "psuh", cmd_psuh, RUN_SETUP}
+----
 
 The options are documented in `builtin.h` under "Adding a new built-in." Since
 we hope to print some data about the user's current workspace context later,
@@ -285,6 +292,8 @@ Modify your `cmd_psuh` implementation to dump the args you're passed, keeping
 existing `printf()` calls in place:
 
 ----
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo UNUSED)
+{
 	int i;
 
 	...
@@ -298,7 +307,8 @@ existing `printf()` calls in place:
 
 	printf(_("Your current working directory:\n<top-level>%s%s\n"),
 	       prefix ? "/" : "", prefix ? prefix : "");
-
+	...
+}
 ----
 
 Build and try it. As you may expect, there's pretty much just whatever we give
-- 
2.48.1

[GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility

[K Jayatheerth]

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 57 ++++++++++++++++++--------
 1 file changed, 39 insertions(+), 18 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index 34a0336898..8f52ebea0c 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -316,26 +316,47 @@ on the command line, including the name of our command. (If `prefix` is empty
 for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
 helpful. So what other context can we get?
 
-Add a line to `#include "config.h"`. Then, add the following bits to the
+Add `#include "config.h"` and `#include "repository.h"`. Then, add the following bits to the
 function body:
 
 ----
-	const char *cfg_name;
+#include "builtin.h"
+#include "gettext.h"
+#include "config.h"
+#include "repository.h"  // Required for repo_config_get_string_tmp()
 
-...
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
+{
+    const char *cfg_name;
+
+    printf(Q_("Your args (there is %d):\n",
+              "Your args (there are %d):\n",
+              argc),
+           argc);
+
+    for (int i = 0; i < argc; i++) {
+        printf("%d: %s\n", i, argv[i]);
+    }
 
-	git_config(git_default_config, NULL);
-	if (git_config_get_string_tmp("user.name", &cfg_name) > 0)
-		printf(_("No name is found in config\n"));
-	else
-		printf(_("Your name: %s\n"), cfg_name);
+    printf(_("Your current working directory:\n<top-level>%s%s\n"),
+           prefix ? "/" : "", prefix ? prefix : "");
+
+    repo_config(repo, git_default_config, NULL);
+
+    if (repo_config_get_string_tmp(repo, "user.name", &cfg_name))
+        printf(_("No name is found in config\n"));
+    else
+        printf(_("Your name: %s\n"), cfg_name);
+
+    return 0;
+}
 ----
 
-`git_config()` will grab the configuration from config files known to Git and
-apply standard precedence rules. `git_config_get_string_tmp()` will look up
+`repo_config()` will grab the configuration from config files known to Git and
+apply standard precedence rules. `repo_config_get_string_tmp()` will look up
 a specific key ("user.name") and give you the value. There are a number of
 single-key lookup functions like this one; you can see them all (and more info
-about how to use `git_config()`) in `Documentation/technical/api-config.adoc`.
+about how to use `repo_config()` ) in `Documentation/git-config.adoc`.
 
 You should see that the name printed matches the one you see when you run:
 
@@ -383,8 +404,8 @@ prepare it, and print its contents:
 
 ...
 
-	wt_status_prepare(the_repository, &status);
-	git_config(git_default_config, &status);
+	wt_status_prepare(repo, &status);
+	repo_config(repo, git_default_config, &status);
 
 ...
 
@@ -1093,11 +1114,11 @@ The one generated for `psuh` from the sample implementation looks like this:
 
 ----
  Documentation/git-psuh.adoc | 40 +++++++++++++++++++++
- Makefile                    |  1 +
- builtin.h                   |  1 +
- builtin/psuh.c              | 73 ++++++++++++++++++++++++++++++++++++++
- git.c                       |  1 +
- t/t9999-psuh-tutorial.sh    | 12 +++++++
+ Makefile                   |  1 +
+ builtin.h                  |  1 +
+ builtin/psuh.c             | 73 ++++++++++++++++++++++++++++++++++++++
+ git.c                      |  1 +
+ t/t9999-psuh-tutorial.sh   | 12 +++++++
  6 files changed, 128 insertions(+)
  create mode 100644 Documentation/git-psuh.adoc
  create mode 100644 builtin/psuh.c
-- 
2.48.1

Re: [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility

[JAYATHEERTH K]

I've sent a pull request completing all the checks [1]

This has no conflict,
as asked [2] I've divided these into three patches for ease of understanding
and I'm expecting feedback.


1.https://github.com/git/git/pull/1917
2.https://public-inbox.org/git/CA+rGoLfrJ-+QVb5=zc=j84sM=MTz3nt8NMYgXVZdfYf70AuDZA@mail.gmail.com/T/#t

Thank you,
Jay

Re: [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites

[Junio C Hamano]

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:

> Subject: Re: [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites

Subject: [PATCH] MyFirstContribution: the mentoring mailing list is no more

> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
>  Documentation/MyFirstContribution.adoc | 8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> index afcf4b46c1..f7e510e6c1 100644
> --- a/Documentation/MyFirstContribution.adoc
> +++ b/Documentation/MyFirstContribution.adoc
> @@ -13,6 +13,7 @@ the Git tree, sending it for review, and making changes based on comments.
>  
>  This tutorial assumes you're already fairly familiar with using Git to manage
>  source code.  The Git workflow steps will largely remain unexplained.
> +This tutorial also assumes you know/understand C programming language in a good capacity.

The lines near this line in the original are already so, but this
new line is way overly long.  Can you wrap it at around 70 chars (do
not line wrap the first line that is 78-columns wide)?

> @@ -40,13 +41,6 @@ the list by sending an email to <git+subscribe@vger.kernel.org>
>  The https://lore.kernel.org/git[archive] of this mailing list is
>  available to view in a browser.
>  
> -==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]
> -
> -This mailing list is targeted to new contributors and was created as a place to
> -post questions and receive answers outside of the public eye of the main list.
> -Veteran contributors who are especially interested in helping mentor newcomers
> -are present on the list. In order to avoid search indexers, group membership is
> -required to view messages; anyone can join and no approval is required.

Nice.  Thanks.

>  
>  ==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat

[GSOC][PATCH v2] Remove outdated mentoring mailing list reference

[K Jayatheerth]

and clarify tutorial prerequisites

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index afcf4b46c1..7b856be41e 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -13,6 +13,7 @@ the Git tree, sending it for review, and making changes based on comments.
 
 This tutorial assumes you're already fairly familiar with using Git to manage
 source code.  The Git workflow steps will largely remain unexplained.
+This tutorial also assumes you know/understand C programming.
 
 [[related-reading]]
 === Related Reading
@@ -40,13 +41,6 @@ the list by sending an email to <git+subscribe@vger.kernel.org>
 The https://lore.kernel.org/git[archive] of this mailing list is
 available to view in a browser.
 
-==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]
-
-This mailing list is targeted to new contributors and was created as a place to
-post questions and receive answers outside of the public eye of the main list.
-Veteran contributors who are especially interested in helping mentor newcomers
-are present on the list. In order to avoid search indexers, group membership is
-required to view messages; anyone can join and no approval is required.
 
 ==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat
 
-- 
2.48.1

Re: [GSOC][PATCH v2] Remove outdated mentoring mailing list reference

[Junio C Hamano]

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:

> Subject: Re: [GSOC][PATCH v2] Remove outdated mentoring mailing list reference

[Documentation/SubmittingPatches]

    The first line of the commit message should be a short description (50
    characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
    and should skip the full stop.  It is also conventional in most cases to
    prefix the first line with "area: " where the area is a filename or
    identifier for the general area of the code being modified, e.g.

    * doc: clarify distinction between sign-off and pgp-signing
    * githooks.txt: improve the intro section

    If in doubt which identifier to use, run `git log --no-merges` on the
    files you are modifying to see the current conventions.

> and clarify tutorial prerequisites

Do not do this.  What you have on the e-mail "Subject:" line is the
first paragraph (whose definition is block of text delineated by
blank lines) of the commit log message, and the first paratraph in
the body of a patch e-mail is the second paragraph.  You do not
start your second paragraph at half-sentence, as if it were a
continuation of an incomplete previous sentence.

[[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq

[K Jayatheerth]

The git-mentoring mailing list is no longer active, so remove its reference
from the documentation. Additionally, clarify that this tutorial assumes
familiarity with C programming.

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index afcf4b46c1..7b856be41e 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -13,6 +13,7 @@ the Git tree, sending it for review, and making changes based on comments.
 
 This tutorial assumes you're already fairly familiar with using Git to manage
 source code.  The Git workflow steps will largely remain unexplained.
+This tutorial also assumes you know/understand C programming.
 
 [[related-reading]]
 === Related Reading
@@ -40,13 +41,6 @@ the list by sending an email to <git+subscribe@vger.kernel.org>
 The https://lore.kernel.org/git[archive] of this mailing list is
 available to view in a browser.
 
-==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]
-
-This mailing list is targeted to new contributors and was created as a place to
-post questions and receive answers outside of the public eye of the main list.
-Veteran contributors who are especially interested in helping mentor newcomers
-are present on the list. In order to avoid search indexers, group membership is
-required to view messages; anyone can join and no approval is required.
 
 ==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat
 
-- 
2.48.1

[[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro

[K Jayatheerth]

Modify function signatures to include struct repository
for better compatibility. Also update builtin.h
accordingly and use UNUSED to prevent warnings.

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index 7b856be41e..45efe117ab 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -142,9 +142,13 @@ followed by the name of the subcommand, in a source file named after the
 subcommand and contained within `builtin/`. So it makes sense to implement your
 command in `builtin/psuh.c`. Create that file, and within it, write the entry
 point for your command in a function matching the style and signature:
-
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix)
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
+----
+Before proceeding further, we should use the UNUSED macro to suppress warnings about unused parameters in the function.
+This prevents the compiler from generating warnings when certain parameters are not used within the function body:
+----
+int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
 ----
 
 We'll also need to add the declaration of psuh; open up `builtin.h`, find the
@@ -152,7 +156,7 @@ declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
 in order to keep the declarations alphabetically sorted:
 
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix);
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo);
 ----
 
 Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
@@ -168,7 +172,7 @@ Throughout the tutorial, we will mark strings for translation as necessary; you
 should also do so when writing your user-facing commands in the future.
 
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix)
+int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
 {
 	printf(_("Pony saying hello goes here.\n"));
 	return 0;
@@ -199,6 +203,9 @@ with the command name, a function pointer to the command implementation, and a
 setup option flag. For now, let's keep mimicking `push`. Find the line where
 `cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
 line in alphabetical order (immediately before `cmd_pull`).
+----
+{ "psuh", cmd_psuh, RUN_SETUP}
+----
 
 The options are documented in `builtin.h` under "Adding a new built-in." Since
 we hope to print some data about the user's current workspace context later,
@@ -285,6 +292,8 @@ Modify your `cmd_psuh` implementation to dump the args you're passed, keeping
 existing `printf()` calls in place:
 
 ----
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo UNUSED)
+{
 	int i;
 
 	...
@@ -298,7 +307,8 @@ existing `printf()` calls in place:
 
 	printf(_("Your current working directory:\n<top-level>%s%s\n"),
 	       prefix ? "/" : "", prefix ? prefix : "");
-
+	...
+}
 ----
 
 Build and try it. As you may expect, there's pretty much just whatever we give
-- 
2.48.1

Re: [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro

[Junio C Hamano]

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:

> Modify function signatures to include struct repository
> for better compatibility. Also update builtin.h
> accordingly and use UNUSED to prevent warnings.

You want to be a bit stronger than "better compatibility" here
(besides, it is unclear what you are trying to be compatible).


    Since 9b1cb507 (builtin: add a repository parameter for builtin
    functions, 2024-09-13), a built-in implementation like cmd_psuh
    is called with a pointer to a "struct repository"; adjust the
    examples to match the current practice.

or something, perhaps?

> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
>  Documentation/MyFirstContribution.adoc | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> index 7b856be41e..45efe117ab 100644
> --- a/Documentation/MyFirstContribution.adoc
> +++ b/Documentation/MyFirstContribution.adoc
> @@ -142,9 +142,13 @@ followed by the name of the subcommand, in a source file named after the
>  subcommand and contained within `builtin/`. So it makes sense to implement your
>  command in `builtin/psuh.c`. Create that file, and within it, write the entry
>  point for your command in a function matching the style and signature:
> -
>  ----
> -int cmd_psuh(int argc, const char **argv, const char *prefix)
> +int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
> +----
> +Before proceeding further, we should use the UNUSED macro to suppress warnings about unused parameters in the function.
> +This prevents the compiler from generating warnings when certain parameters are not used within the function body:
> +----
> +int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
>  ----
>  
>  We'll also need to add the declaration of psuh; open up `builtin.h`, find the
> @@ -152,7 +156,7 @@ declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
>  in order to keep the declarations alphabetically sorted:
>  
>  ----
> -int cmd_psuh(int argc, const char **argv, const char *prefix);
> +int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo);
>  ----
>  
>  Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
> @@ -168,7 +172,7 @@ Throughout the tutorial, we will mark strings for translation as necessary; you
>  should also do so when writing your user-facing commands in the future.
>  
>  ----
> -int cmd_psuh(int argc, const char **argv, const char *prefix)
> +int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
>  {
>  	printf(_("Pony saying hello goes here.\n"));
>  	return 0;
> @@ -199,6 +203,9 @@ with the command name, a function pointer to the command implementation, and a
>  setup option flag. For now, let's keep mimicking `push`. Find the line where
>  `cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
>  line in alphabetical order (immediately before `cmd_pull`).
> +----
> +{ "psuh", cmd_psuh, RUN_SETUP}
> +----
>  
>  The options are documented in `builtin.h` under "Adding a new built-in." Since
>  we hope to print some data about the user's current workspace context later,
> @@ -285,6 +292,8 @@ Modify your `cmd_psuh` implementation to dump the args you're passed, keeping
>  existing `printf()` calls in place:
>  
>  ----
> +int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo UNUSED)
> +{
>  	int i;
>  
>  	...
> @@ -298,7 +307,8 @@ existing `printf()` calls in place:
>  
>  	printf(_("Your current working directory:\n<top-level>%s%s\n"),
>  	       prefix ? "/" : "", prefix ? prefix : "");
> -
> +	...
> +}
>  ----
>  
>  Build and try it. As you may expect, there's pretty much just whatever we give

[[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[K Jayatheerth]

Refactor config handling by replacing git_config(...)
with repo_config(...) for better repository context
awareness and alignment with modern Git practices.

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 57 ++++++++++++++++++--------
 1 file changed, 39 insertions(+), 18 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index 45efe117ab..3ae85016d4 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -316,26 +316,47 @@ on the command line, including the name of our command. (If `prefix` is empty
 for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
 helpful. So what other context can we get?
 
-Add a line to `#include "config.h"`. Then, add the following bits to the
+Add `#include "config.h"` and `#include "repository.h"`. Then, add the following bits to the
 function body:
 
 ----
-	const char *cfg_name;
+#include "builtin.h"
+#include "gettext.h"
+#include "config.h"
+#include "repository.h"  // Required for repo_config_get_string_tmp()
 
-...
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
+{
+    const char *cfg_name;
+
+    printf(Q_("Your args (there is %d):\n",
+              "Your args (there are %d):\n",
+              argc),
+           argc);
+
+    for (int i = 0; i < argc; i++) {
+        printf("%d: %s\n", i, argv[i]);
+    }
 
-	git_config(git_default_config, NULL);
-	if (git_config_get_string_tmp("user.name", &cfg_name) > 0)
-		printf(_("No name is found in config\n"));
-	else
-		printf(_("Your name: %s\n"), cfg_name);
+    printf(_("Your current working directory:\n<top-level>%s%s\n"),
+           prefix ? "/" : "", prefix ? prefix : "");
+
+    repo_config(repo, git_default_config, NULL);
+
+    if (repo_config_get_string_tmp(repo, "user.name", &cfg_name))
+        printf(_("No name is found in config\n"));
+    else
+        printf(_("Your name: %s\n"), cfg_name);
+
+    return 0;
+}
 ----
 
-`git_config()` will grab the configuration from config files known to Git and
-apply standard precedence rules. `git_config_get_string_tmp()` will look up
+`repo_config()` will grab the configuration from config files known to Git and
+apply standard precedence rules. `repo_config_get_string_tmp()` will look up
 a specific key ("user.name") and give you the value. There are a number of
 single-key lookup functions like this one; you can see them all (and more info
-about how to use `git_config()`) in `Documentation/technical/api-config.adoc`.
+about how to use `repo_config()` ) in `Documentation/git-config.adoc`.
 
 You should see that the name printed matches the one you see when you run:
 
@@ -383,8 +404,8 @@ prepare it, and print its contents:
 
 ...
 
-	wt_status_prepare(the_repository, &status);
-	git_config(git_default_config, &status);
+	wt_status_prepare(repo, &status);
+	repo_config(repo, git_default_config, &status);
 
 ...
 
@@ -1093,11 +1114,11 @@ The one generated for `psuh` from the sample implementation looks like this:
 
 ----
  Documentation/git-psuh.adoc | 40 +++++++++++++++++++++
- Makefile                    |  1 +
- builtin.h                   |  1 +
- builtin/psuh.c              | 73 ++++++++++++++++++++++++++++++++++++++
- git.c                       |  1 +
- t/t9999-psuh-tutorial.sh    | 12 +++++++
+ Makefile                   |  1 +
+ builtin.h                  |  1 +
+ builtin/psuh.c             | 73 ++++++++++++++++++++++++++++++++++++++
+ git.c                      |  1 +
+ t/t9999-psuh-tutorial.sh   | 12 +++++++
  6 files changed, 128 insertions(+)
  create mode 100644 Documentation/git-psuh.adoc
  create mode 100644 builtin/psuh.c
-- 
2.48.1

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[Junio C Hamano]

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:

> Refactor config handling by replacing git_config(...)
> with repo_config(...) for better repository context
> awareness and alignment with modern Git practices.
>
> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
>  Documentation/MyFirstContribution.adoc | 57 ++++++++++++++++++--------
>  1 file changed, 39 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> index 45efe117ab..3ae85016d4 100644
> --- a/Documentation/MyFirstContribution.adoc
> +++ b/Documentation/MyFirstContribution.adoc
> @@ -316,26 +316,47 @@ on the command line, including the name of our command. (If `prefix` is empty
>  for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
>  helpful. So what other context can we get?
>  
> -Add a line to `#include "config.h"`. Then, add the following bits to the
> +Add `#include "config.h"` and `#include "repository.h"`. Then, add the following bits to the
>  function body:
>  
>  ----
> -	const char *cfg_name;
> +#include "builtin.h"
> +#include "gettext.h"
> +#include "config.h"
> +#include "repository.h"  // Required for repo_config_get_string_tmp()

I do not think we updated Coding Guidelines to allow // comments.

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[JAYATHEERTH K]

On Mon, Mar 24, 2025 at 3:38 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
>
> > Refactor config handling by replacing git_config(...)
> > with repo_config(...) for better repository context
> > awareness and alignment with modern Git practices.
> >
> > Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> > ---
> >  Documentation/MyFirstContribution.adoc | 57 ++++++++++++++++++--------
> >  1 file changed, 39 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> > index 45efe117ab..3ae85016d4 100644
> > --- a/Documentation/MyFirstContribution.adoc
> > +++ b/Documentation/MyFirstContribution.adoc
> > @@ -316,26 +316,47 @@ on the command line, including the name of our command. (If `prefix` is empty
> >  for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
> >  helpful. So what other context can we get?
> >
> > -Add a line to `#include "config.h"`. Then, add the following bits to the
> > +Add `#include "config.h"` and `#include "repository.h"`. Then, add the following bits to the
> >  function body:
> >
> >  ----
> > -     const char *cfg_name;
> > +#include "builtin.h"
> > +#include "gettext.h"
> > +#include "config.h"
> > +#include "repository.h"  // Required for repo_config_get_string_tmp()
>
> I do not think we updated Coding Guidelines to allow // comments.
>
Since this was a tutorial I thought this was helpful, anyways I will
remove the comments, because I get that this would be bad practice for
newbies.

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[Junio C Hamano]

JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> writes:

>> > +#include "builtin.h"
>> > +#include "gettext.h"
>> > +#include "config.h"
>> > +#include "repository.h"  // Required for repo_config_get_string_tmp()
>>
>> I do not think we updated Coding Guidelines to allow // comments.
>>
> Since this was a tutorial I thought this was helpful, anyways I will
> remove the comments, because I get that this would be bad practice for
> newbies.

I meant that I think our guidelines frowns upon

	#include "foo.h" // for bar()

I didn't mean a comment is necessarily bad.  IOW,

	#include "foo.h" /* for bar() */

may be OK.

But real programs will evolve and API elements that are used from a
header file will change over time, so it may not be a good idea to
single out a function like that in the comment.  It would be much
better to explain _why_ each change is made in the text that
precedes the sample code.  E.g.

    Add `#include "config.h"` because you want to use X and Y,
    and `#include "repository.h"` because you want to use Z.

    Then, add the following bits to the function body:

     ----
    #include "builtin.h"
    #include "gettext.h"
    #include "config.h"
    #include "repository.h"
    ...
    int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
    {
        const char *cfg_name;

        printf(Q_("Your args (there is %d):\n",

[[GSOC][PATCH v4] 2/3] docs: update function signature, add UNUSED macro

[K Jayatheerth]

Since 9b1cb507 (builtin: add a repository parameter
for builtin functions,  2024-09-13), built-in
commands now receive a `struct repository *` argument
for improved repository context handling.
Update example function signatures in the documentation
to align with this current convention.

Also, update `builtin.h` accordingly
and use the `UNUSED` macro to suppress
warnings for unused parameters in example code.

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index 7b856be41e..45efe117ab 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -142,9 +142,13 @@ followed by the name of the subcommand, in a source file named after the
 subcommand and contained within `builtin/`. So it makes sense to implement your
 command in `builtin/psuh.c`. Create that file, and within it, write the entry
 point for your command in a function matching the style and signature:
-
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix)
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
+----
+Before proceeding further, we should use the UNUSED macro to suppress warnings about unused parameters in the function.
+This prevents the compiler from generating warnings when certain parameters are not used within the function body:
+----
+int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
 ----
 
 We'll also need to add the declaration of psuh; open up `builtin.h`, find the
@@ -152,7 +156,7 @@ declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
 in order to keep the declarations alphabetically sorted:
 
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix);
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo);
 ----
 
 Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
@@ -168,7 +172,7 @@ Throughout the tutorial, we will mark strings for translation as necessary; you
 should also do so when writing your user-facing commands in the future.
 
 ----
-int cmd_psuh(int argc, const char **argv, const char *prefix)
+int cmd_psuh(int argc UNUSED, const char **argv UNUSED, const char *prefix UNUSED, struct repository *repo UNUSED)
 {
 	printf(_("Pony saying hello goes here.\n"));
 	return 0;
@@ -199,6 +203,9 @@ with the command name, a function pointer to the command implementation, and a
 setup option flag. For now, let's keep mimicking `push`. Find the line where
 `cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
 line in alphabetical order (immediately before `cmd_pull`).
+----
+{ "psuh", cmd_psuh, RUN_SETUP}
+----
 
 The options are documented in `builtin.h` under "Adding a new built-in." Since
 we hope to print some data about the user's current workspace context later,
@@ -285,6 +292,8 @@ Modify your `cmd_psuh` implementation to dump the args you're passed, keeping
 existing `printf()` calls in place:
 
 ----
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo UNUSED)
+{
 	int i;
 
 	...
@@ -298,7 +307,8 @@ existing `printf()` calls in place:
 
 	printf(_("Your current working directory:\n<top-level>%s%s\n"),
 	       prefix ? "/" : "", prefix ? prefix : "");
-
+	...
+}
 ----
 
 Build and try it. As you may expect, there's pretty much just whatever we give
-- 
2.48.1

[[GSOC][PATCH v4] 3/3] docs: replace git_config with repo_config

[K Jayatheerth]

Refactor config handling by replacing git_config(...)
with repo_config(...) for better repository context
awareness and alignment with modern Git practices.

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
 Documentation/MyFirstContribution.adoc | 57 ++++++++++++++++++--------
 1 file changed, 39 insertions(+), 18 deletions(-)

diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
index 45efe117ab..04c19ac0b2 100644
--- a/Documentation/MyFirstContribution.adoc
+++ b/Documentation/MyFirstContribution.adoc
@@ -316,26 +316,47 @@ on the command line, including the name of our command. (If `prefix` is empty
 for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
 helpful. So what other context can we get?
 
-Add a line to `#include "config.h"`. Then, add the following bits to the
+Add `#include "config.h"` and `#include "repository.h"`. Then, add the following bits to the
 function body:
 
 ----
-	const char *cfg_name;
+#include "builtin.h"
+#include "gettext.h"
+#include "config.h"
+#include "repository.h"  
 
-...
+int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
+{
+    const char *cfg_name;
+
+    printf(Q_("Your args (there is %d):\n",
+              "Your args (there are %d):\n",
+              argc),
+           argc);
+
+    for (int i = 0; i < argc; i++) {
+        printf("%d: %s\n", i, argv[i]);
+    }
 
-	git_config(git_default_config, NULL);
-	if (git_config_get_string_tmp("user.name", &cfg_name) > 0)
-		printf(_("No name is found in config\n"));
-	else
-		printf(_("Your name: %s\n"), cfg_name);
+    printf(_("Your current working directory:\n<top-level>%s%s\n"),
+           prefix ? "/" : "", prefix ? prefix : "");
+
+    repo_config(repo, git_default_config, NULL);
+
+    if (repo_config_get_string_tmp(repo, "user.name", &cfg_name))
+        printf(_("No name is found in config\n"));
+    else
+        printf(_("Your name: %s\n"), cfg_name);
+
+    return 0;
+}
 ----
 
-`git_config()` will grab the configuration from config files known to Git and
-apply standard precedence rules. `git_config_get_string_tmp()` will look up
+`repo_config()` will grab the configuration from config files known to Git and
+apply standard precedence rules. `repo_config_get_string_tmp()` will look up
 a specific key ("user.name") and give you the value. There are a number of
 single-key lookup functions like this one; you can see them all (and more info
-about how to use `git_config()`) in `Documentation/technical/api-config.adoc`.
+about how to use `repo_config()` ) in `Documentation/git-config.adoc`.
 
 You should see that the name printed matches the one you see when you run:
 
@@ -383,8 +404,8 @@ prepare it, and print its contents:
 
 ...
 
-	wt_status_prepare(the_repository, &status);
-	git_config(git_default_config, &status);
+	wt_status_prepare(repo, &status);
+	repo_config(repo, git_default_config, &status);
 
 ...
 
@@ -1093,11 +1114,11 @@ The one generated for `psuh` from the sample implementation looks like this:
 
 ----
  Documentation/git-psuh.adoc | 40 +++++++++++++++++++++
- Makefile                    |  1 +
- builtin.h                   |  1 +
- builtin/psuh.c              | 73 ++++++++++++++++++++++++++++++++++++++
- git.c                       |  1 +
- t/t9999-psuh-tutorial.sh    | 12 +++++++
+ Makefile                   |  1 +
+ builtin.h                  |  1 +
+ builtin/psuh.c             | 73 ++++++++++++++++++++++++++++++++++++++
+ git.c                      |  1 +
+ t/t9999-psuh-tutorial.sh   | 12 +++++++
  6 files changed, 128 insertions(+)
  create mode 100644 Documentation/git-psuh.adoc
  create mode 100644 builtin/psuh.c
-- 
2.48.1

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[JAYATHEERTH K]

On Mon, Mar 24, 2025 at 10:16 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> writes:
>
> >> > +#include "builtin.h"
> >> > +#include "gettext.h"
> >> > +#include "config.h"
> >> > +#include "repository.h"  // Required for repo_config_get_string_tmp()
> >>
> >> I do not think we updated Coding Guidelines to allow // comments.
> >>
> > Since this was a tutorial I thought this was helpful, anyways I will
> > remove the comments, because I get that this would be bad practice for
> > newbies.
>
> I meant that I think our guidelines frowns upon
>
>         #include "foo.h" // for bar()
>
> I didn't mean a comment is necessarily bad.  IOW,
>
>         #include "foo.h" /* for bar() */
>
> may be OK.
>
> But real programs will evolve and API elements that are used from a
> header file will change over time, so it may not be a good idea to
> single out a function like that in the comment.  It would be much
> better to explain _why_ each change is made in the text that
> precedes the sample code.  E.g.
>
>     Add `#include "config.h"` because you want to use X and Y,
>     and `#include "repository.h"` because you want to use Z.
>
>     Then, add the following bits to the function body:
>
>      ----
>     #include "builtin.h"
>     #include "gettext.h"
>     #include "config.h"
>     #include "repository.h"
>     ...
>     int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo)
>     {
>         const char *cfg_name;
>
>         printf(Q_("Your args (there is %d):\n",
>
>
>

In the latest patch version I've removed the comments, since we
already added a line above saying the user has to include
`repository.h` I don't think we need to go in depth into that, do let
me know if that is not the case, looking forward to any more feedback.

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[Junio C Hamano]

JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> writes:

>> ... better to explain _why_ each change is made in the text that
>> precedes the sample code.  E.g.
>>
>>     Add `#include "config.h"` because you want to use X and Y,
>>     and `#include "repository.h"` because you want to use Z.
>>
>> ...
> In the latest patch version I've removed the comments, since we
> already added a line above saying the user has to include
> `repository.h` I don't think we need to go in depth into that, do let
> me know if that is not the case, looking forward to any more feedback.

It's your patch, after all.

But if the reason why you added the comment was "this is a tutorial"
as you said, I would imagine that it would help readers to say why
a particular header is needed, when the tutorial text tells them
that they need to add it.  From a quick look at the patch, it seems
that the updated text says what the change did (i.e. add a header),
which is rather obvious in the sample code, without saying why the
addition is necessary?

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[JAYATHEERTH K]

On Wed, Mar 26, 2025 at 8:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> writes:
>
> >> ... better to explain _why_ each change is made in the text that
> >> precedes the sample code.  E.g.
> >>
> >>     Add `#include "config.h"` because you want to use X and Y,
> >>     and `#include "repository.h"` because you want to use Z.
> >>
> >> ...
> > In the latest patch version I've removed the comments, since we
> > already added a line above saying the user has to include
> > `repository.h` I don't think we need to go in depth into that, do let
> > me know if that is not the case, looking forward to any more feedback.
>
> It's your patch, after all.
>
> But if the reason why you added the comment was "this is a tutorial"
> as you said, I would imagine that it would help readers to say why
> a particular header is needed, when the tutorial text tells them
> that they need to add it.  From a quick look at the patch, it seems
> that the updated text says what the change did (i.e. add a header),
> which is rather obvious in the sample code, without saying why the
> addition is necessary?
>

Agreed, but there will be two things from this point, in the previous
documentation itself the header files didn't have very detailed
explanation. If I do a detailed description of the header files in
this specific tutorial/patch, the documentation will look
inconsistent.

I could do three things,

1. If these series of patches do not have any other faults/feedback,
after merging them I could start working on a second microproject
(Adding the details of header files of the whole document
consistently).

2. I could present a change in this current patch to improve the
details of the header files and re send the patch.

3. We can just leave this as is.

I'm inclined towards the first idea, as I think this will cover my
GSOC timeline and also give me some time to work on my proposal and
fulfill my requirements for GSOC at the same time, and also makes the
documentation good for newbies.

But I'm willing to work with either of these ideas, or any new method
you want to proceed with.


I think the prev email was rendered in HTML
So I resent this.


Thank you,
Jay

Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config

[JAYATHEERTH K]

Hey Junio,

I think this email has missed your attention.
Apologies for persisting,
but I think it would be helpful to know how to proceed with this.

Thank You,
Jay

Re: [GSOC][PATCH v2] Remove outdated mentoring mailing list reference

[JAYATHEERTH K]

On Fri, Mar 21, 2025 at 4:06 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
>
> > Subject: Re: [GSOC][PATCH v2] Remove outdated mentoring mailing list reference
>
> [Documentation/SubmittingPatches]
>
>     The first line of the commit message should be a short description (50
>     characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]),
>     and should skip the full stop.  It is also conventional in most cases to
>     prefix the first line with "area: " where the area is a filename or
>     identifier for the general area of the code being modified, e.g.
>

Went through the discussion

>     * doc: clarify distinction between sign-off and pgp-signing
>     * githooks.txt: improve the intro section
>
>     If in doubt which identifier to use, run `git log --no-merges` on the
>     files you are modifying to see the current conventions.
>
> > and clarify tutorial prerequisites
>
> Do not do this.  What you have on the e-mail "Subject:" line is the
> first paragraph (whose definition is block of text delineated by
> blank lines) of the commit log message, and the first paratraph in
> the body of a patch e-mail is the second paragraph.  You do not
> start your second paragraph at half-sentence, as if it were a
> continuation of an incomplete previous sentence.
>
Thank you for the feedback, I will make sure not to repeat them in the
further patches

-Jay