* [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites
@ 2025-03-15 18:15 K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 2/3] Update function signature and UNUSED to include struct repository and modify builtin.h accordingly K Jayatheerth
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: K Jayatheerth @ 2025-03-15 18:15 UTC (permalink / raw)
To: git; +Cc: ben.knoble, 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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [GSOC][PATCH 2/3] Update function signature and UNUSED to include struct repository and modify builtin.h accordingly
2025-03-15 18:15 [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites K Jayatheerth
@ 2025-03-15 18:15 ` K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility K Jayatheerth
2025-03-17 21:57 ` [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites Junio C Hamano
2 siblings, 0 replies; 21+ messages in thread
From: K Jayatheerth @ 2025-03-15 18:15 UTC (permalink / raw)
To: git; +Cc: ben.knoble, 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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility
2025-03-15 18:15 [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 2/3] Update function signature and UNUSED to include struct repository and modify builtin.h accordingly K Jayatheerth
@ 2025-03-15 18:15 ` K Jayatheerth
2025-03-15 18:21 ` JAYATHEERTH K
2025-03-17 21:57 ` [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites Junio C Hamano
2 siblings, 1 reply; 21+ messages in thread
From: K Jayatheerth @ 2025-03-15 18:15 UTC (permalink / raw)
To: git; +Cc: ben.knoble, 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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility
2025-03-15 18:15 ` [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility K Jayatheerth
@ 2025-03-15 18:21 ` JAYATHEERTH K
0 siblings, 0 replies; 21+ messages in thread
From: JAYATHEERTH K @ 2025-03-15 18:21 UTC (permalink / raw)
To: git; +Cc: ben.knoble
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites
2025-03-15 18:15 [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 2/3] Update function signature and UNUSED to include struct repository and modify builtin.h accordingly K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility K Jayatheerth
@ 2025-03-17 21:57 ` Junio C Hamano
2025-03-19 17:02 ` [GSOC][PATCH v2] Remove outdated mentoring mailing list reference K Jayatheerth
2 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2025-03-17 21:57 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, ben.knoble
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [GSOC][PATCH v2] Remove outdated mentoring mailing list reference
2025-03-17 21:57 ` [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites Junio C Hamano
@ 2025-03-19 17:02 ` K Jayatheerth
2025-03-21 10:36 ` Junio C Hamano
0 siblings, 1 reply; 21+ messages in thread
From: K Jayatheerth @ 2025-03-19 17:02 UTC (permalink / raw)
To: git; +Cc: ben.knoble, gitster, jayatheerthkulkarni2005
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [GSOC][PATCH v2] Remove outdated mentoring mailing list reference
2025-03-19 17:02 ` [GSOC][PATCH v2] Remove outdated mentoring mailing list reference K Jayatheerth
@ 2025-03-21 10:36 ` Junio C Hamano
2025-03-21 14:30 ` [[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq K Jayatheerth
2025-03-21 14:32 ` [GSOC][PATCH v2] Remove outdated mentoring mailing list reference JAYATHEERTH K
0 siblings, 2 replies; 21+ messages in thread
From: Junio C Hamano @ 2025-03-21 10:36 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, ben.knoble
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq
2025-03-21 10:36 ` Junio C Hamano
@ 2025-03-21 14:30 ` K Jayatheerth
2025-03-21 14:30 ` [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
2025-03-21 14:30 ` [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config K Jayatheerth
2025-03-21 14:32 ` [GSOC][PATCH v2] Remove outdated mentoring mailing list reference JAYATHEERTH K
1 sibling, 2 replies; 21+ messages in thread
From: K Jayatheerth @ 2025-03-21 14:30 UTC (permalink / raw)
To: git; +Cc: gitster, ben.knoble, jayatheerthkulkarni2005
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro
2025-03-21 14:30 ` [[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq K Jayatheerth
@ 2025-03-21 14:30 ` K Jayatheerth
2025-03-23 22:08 ` Junio C Hamano
2025-03-21 14:30 ` [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config K Jayatheerth
1 sibling, 1 reply; 21+ messages in thread
From: K Jayatheerth @ 2025-03-21 14:30 UTC (permalink / raw)
To: git; +Cc: gitster, ben.knoble, jayatheerthkulkarni2005
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-21 14:30 ` [[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq K Jayatheerth
2025-03-21 14:30 ` [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
@ 2025-03-21 14:30 ` K Jayatheerth
2025-03-23 22:08 ` Junio C Hamano
1 sibling, 1 reply; 21+ messages in thread
From: K Jayatheerth @ 2025-03-21 14:30 UTC (permalink / raw)
To: git; +Cc: gitster, ben.knoble, jayatheerthkulkarni2005
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [GSOC][PATCH v2] Remove outdated mentoring mailing list reference
2025-03-21 10:36 ` Junio C Hamano
2025-03-21 14:30 ` [[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq K Jayatheerth
@ 2025-03-21 14:32 ` JAYATHEERTH K
1 sibling, 0 replies; 21+ messages in thread
From: JAYATHEERTH K @ 2025-03-21 14:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ben.knoble
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-21 14:30 ` [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config K Jayatheerth
@ 2025-03-23 22:08 ` Junio C Hamano
2025-03-24 1:42 ` JAYATHEERTH K
0 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2025-03-23 22:08 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, ben.knoble
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro
2025-03-21 14:30 ` [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
@ 2025-03-23 22:08 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2025-03-23 22:08 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, ben.knoble
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-23 22:08 ` Junio C Hamano
@ 2025-03-24 1:42 ` JAYATHEERTH K
2025-03-24 4:46 ` Junio C Hamano
0 siblings, 1 reply; 21+ messages in thread
From: JAYATHEERTH K @ 2025-03-24 1:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ben.knoble
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-24 1:42 ` JAYATHEERTH K
@ 2025-03-24 4:46 ` Junio C Hamano
2025-03-24 13:03 ` [[GSOC][PATCH v4] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
2025-03-24 13:10 ` [[GSOC][PATCH v3] " JAYATHEERTH K
0 siblings, 2 replies; 21+ messages in thread
From: Junio C Hamano @ 2025-03-24 4:46 UTC (permalink / raw)
To: JAYATHEERTH K; +Cc: git, ben.knoble
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",
^ permalink raw reply [flat|nested] 21+ messages in thread
* [[GSOC][PATCH v4] 2/3] docs: update function signature, add UNUSED macro
2025-03-24 4:46 ` Junio C Hamano
@ 2025-03-24 13:03 ` K Jayatheerth
2025-03-24 13:03 ` [[GSOC][PATCH v4] 3/3] docs: replace git_config with repo_config K Jayatheerth
2025-03-24 13:10 ` [[GSOC][PATCH v3] " JAYATHEERTH K
1 sibling, 1 reply; 21+ messages in thread
From: K Jayatheerth @ 2025-03-24 13:03 UTC (permalink / raw)
To: gitster; +Cc: ben.knoble, git, jayatheerthkulkarni2005
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [[GSOC][PATCH v4] 3/3] docs: replace git_config with repo_config
2025-03-24 13:03 ` [[GSOC][PATCH v4] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
@ 2025-03-24 13:03 ` K Jayatheerth
0 siblings, 0 replies; 21+ messages in thread
From: K Jayatheerth @ 2025-03-24 13:03 UTC (permalink / raw)
To: gitster; +Cc: ben.knoble, git, jayatheerthkulkarni2005
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-24 4:46 ` Junio C Hamano
2025-03-24 13:03 ` [[GSOC][PATCH v4] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
@ 2025-03-24 13:10 ` JAYATHEERTH K
2025-03-26 2:37 ` Junio C Hamano
1 sibling, 1 reply; 21+ messages in thread
From: JAYATHEERTH K @ 2025-03-24 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ben.knoble
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-24 13:10 ` [[GSOC][PATCH v3] " JAYATHEERTH K
@ 2025-03-26 2:37 ` Junio C Hamano
2025-03-26 3:15 ` JAYATHEERTH K
0 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2025-03-26 2:37 UTC (permalink / raw)
To: JAYATHEERTH K; +Cc: git, ben.knoble
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?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-26 2:37 ` Junio C Hamano
@ 2025-03-26 3:15 ` JAYATHEERTH K
2025-03-29 17:42 ` JAYATHEERTH K
0 siblings, 1 reply; 21+ messages in thread
From: JAYATHEERTH K @ 2025-03-26 3:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ben.knoble
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config
2025-03-26 3:15 ` JAYATHEERTH K
@ 2025-03-29 17:42 ` JAYATHEERTH K
0 siblings, 0 replies; 21+ messages in thread
From: JAYATHEERTH K @ 2025-03-29 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ben.knoble
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
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2025-03-29 17:43 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-15 18:15 [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 2/3] Update function signature and UNUSED to include struct repository and modify builtin.h accordingly K Jayatheerth
2025-03-15 18:15 ` [GSOC][PATCH 3/3] Replace git_config(...) with repo_config(...) for modern Git compatibility K Jayatheerth
2025-03-15 18:21 ` JAYATHEERTH K
2025-03-17 21:57 ` [GSOC][PATCH 1/3] Remove outdated mentoring mailing list reference and clarify tutorial prerequisites Junio C Hamano
2025-03-19 17:02 ` [GSOC][PATCH v2] Remove outdated mentoring mailing list reference K Jayatheerth
2025-03-21 10:36 ` Junio C Hamano
2025-03-21 14:30 ` [[GSOC][PATCH v3] 1/3] docs: drop inactive mentoring list, add C prereq K Jayatheerth
2025-03-21 14:30 ` [[GSOC][PATCH v3] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
2025-03-23 22:08 ` Junio C Hamano
2025-03-21 14:30 ` [[GSOC][PATCH v3] 3/3] docs: replace git_config with repo_config K Jayatheerth
2025-03-23 22:08 ` Junio C Hamano
2025-03-24 1:42 ` JAYATHEERTH K
2025-03-24 4:46 ` Junio C Hamano
2025-03-24 13:03 ` [[GSOC][PATCH v4] 2/3] docs: update function signature, add UNUSED macro K Jayatheerth
2025-03-24 13:03 ` [[GSOC][PATCH v4] 3/3] docs: replace git_config with repo_config K Jayatheerth
2025-03-24 13:10 ` [[GSOC][PATCH v3] " JAYATHEERTH K
2025-03-26 2:37 ` Junio C Hamano
2025-03-26 3:15 ` JAYATHEERTH K
2025-03-29 17:42 ` JAYATHEERTH K
2025-03-21 14:32 ` [GSOC][PATCH v2] Remove outdated mentoring mailing list reference JAYATHEERTH K
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).