threads / rfc / 65070

RFC patchbuiltin/repo.c: change info default behavior to show all fields

Subject: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

## tl;dr

14 messages between Feb 24, 2026 and Feb 25, 2026. Diffs are folded; open one to read it.

replies: 13people: 5as markdown or json

SoutrikDas· Feb 24, 2026, 20:40 UTC · lore
Hi everyone!

I wish to undertake the "Improve repo" GSOC idea,so I was going through the repo.c code and trying to make a small patch.

I saw that by default "git repo info" does not print anything at all, I went through the first discussions [1] :

Show 8 quoted lines
>> Also add a flag --allow-empty, which will force the output data to be
>> empty when no field is requested.
>>
>
> Why do you suppose we need this, I'm not against it, but it would be
> nice to state why this is necessary. The idea is to have a default
> output when a user runs `git repo-info`, so I'm missing why this would
> be useful.
And 
Show 8 quoted lines
> I was thinking about use cases where repo-info is used inside scripts.
> A simple (but kinda useless...) example: an application that is a GUI
> for this command, where the fields are selected in a checkbox, calling
> repo-info with them and then displaying their contents in a dialog.
> 
> In this example, if no field is selected and there's no validation in
> the GUI side, the default set of data will be retrieved. With
> git repo-info --allow-empty, we don't need to care about it.

Would it not be a bit better if we allow the default behaviour to show all fields and then any subsequent scripts or application can make sure to check if they are appending any fields to the git repo info command, if not then dont show anything, because even if they ran the command without any fields they would get nothing.

But now if we change default behaviour to show all fields then it becomes a bit more user friendly.

Show 11 quoted lines
> After this review, I'm starting to think that leaving it empty by default
> would be better. Specially after the review by Phillip Wood [2], who
> has a good argument for it:
> 
> """
>   As this is a plumbing command I think it would be clearer if the caller 
>   was required to specify the output format and the information that they 
>   require with an "--all" option for "show me everything" as Junio 
>   suggested. If we were to set defaults for the format and keys now we 
>   would be stuck with them forever.
> """

I don't really have much experience writing scripts, but ... if one is scripting to get a certain value, would they not specify that ? like why would they excecute a "git repo info" without any fields?

Also ... mayeb this does not make much sense, but the 'git repo info --all' has only 4 fields now, so showing all 4, should be okay ? Or maybe not.

[1] : https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#m04cb1fc694f334cc861f6ab146f50b45ae277874 [2] : https://lore.kernel.org/git/af27af92-73d5-4f0a-84f4-9c91de6ab6e6@gmail.com/ --- Previously, git repo info would print nothing, when invoked without arguements. Change the default behaviour to display all available fields, to make it a little more user friendly.

Signed-off-by: SoutrikDas <valusoutrik@gmail.com>
---
 builtin/repo.c | 2 ++
 1 file changed, 2 insertions(+)
Show changes to builtin/repo.c +2 −0
diff --git a/builtin/repo.c b/builtin/repo.c
index 0ea045abc1..4d7efcd833 100644
--- a/builtin/repo.c
+++ b/builtin/repo.c
@@ -193,6 +193,8 @@ static int cmd_repo_info(int argc, const char **argv, const char *prefix,
 
 	if (all_keys)
 		return print_all_fields(repo, format);
+	else if(!argc)
+		return print_fields(argc, argv, repo, format);
 	else
 		return print_fields(argc, argv, repo, format);
 }
-- 
2.52.0
SoutrikDas· Feb 24, 2026, 21:03 UTC · re: SoutrikDas · lore

[PATCH v2] builtin/repo.c: change info default behavior to show all fields

>  	if (all_keys)
>  		return print_all_fields(repo, format);
> +	else if(!argc)
> +		return print_fields(argc, argv, repo, format);

I did not mean to send the above patch. It was a mistake. ---

Previously, git repo info would print nothing, when invoked without arguements. Change the default behaviour to display all available fields, to make it a little more user friendly.

Signed-off-by: SoutrikDas <valusoutrik@gmail.com>
---
 builtin/repo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to builtin/repo.c +1 −1
diff --git a/builtin/repo.c b/builtin/repo.c
index 0ea045abc1..d044d83b14 100644
--- a/builtin/repo.c
+++ b/builtin/repo.c
@@ -191,7 +191,7 @@ static int cmd_repo_info(int argc, const char **argv, const char *prefix,
 	if (all_keys && argc)
 		die(_("--all and <key> cannot be used together"));
 
-	if (all_keys)
+	if (all_keys || !argc)
 		return print_all_fields(repo, format);
 	else
 		return print_fields(argc, argv, repo, format);
-- 
2.52.0
Junio C Hamano· Feb 24, 2026, 21:23 UTC · re: SoutrikDas · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

SoutrikDas <valusoutrik@gmail.com> writes:
Show 28 quoted lines
>> After this review, I'm starting to think that leaving it empty by default
>> would be better. Specially after the review by Phillip Wood [2], who
>> has a good argument for it:
>> 
>> """
>>   As this is a plumbing command I think it would be clearer if the caller 
>>   was required to specify the output format and the information that they 
>>   require with an "--all" option for "show me everything" as Junio 
>>   suggested. If we were to set defaults for the format and keys now we 
>>   would be stuck with them forever.
>> """
>
> I don't really have much experience writing scripts, but ... if one is 
> scripting to get a certain value, would they not specify that ? like 
> why would they excecute a "git repo info" without any fields?
>
> Also ... mayeb this does not make much sense, but the
> 'git repo info --all' has only 4 fields now, so showing all 4, should be okay ?
> Or maybe not.
>
>
> [1] : https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#m04cb1fc694f334cc861f6ab146f50b45ae277874
> [2] : https://lore.kernel.org/git/af27af92-73d5-4f0a-84f4-9c91de6ab6e6@gmail.com/
> ---
> Previously, git repo info would print nothing,
> when invoked without arguements. Change the default
> behaviour to display all available fields, to make
> it a little more user friendly.

The number of things do not matter. "user friendly" does not matter.

They do not matter plumbing commands intended to be used in scripts. What matters more is being predictable.

The silly example you saw in the discussion thread can be solved even if by default we showed everything. The UI can count the checkboxes it is going to turn into command's arguments (i.e., "I want to ask you about these pieces of information"), and if that is empty, just can refrain from invoking the command. But that is arguably _more_ work on the script. A simpler rule "we give only what you ask, always, no exceptions that depends on the number of things you ask (like when you ask for zero things)" would end up being easier to use.

And it is more predictable. If you ask for two things, you get two things. If you ask for one thing, you get one thing. If you ask for zero things? You get none.

So...?
SoutrikDas· Feb 24, 2026, 22:08 UTC · re: Junio C Hamano · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

> They do not matter plumbing commands intended to be used in scripts.
> What matters more is being predictable.
My bad for this ... I did not know about plumbing commands.
> And it is more predictable.  If you ask for two things, you get two
> things.  If you ask for one thing, you get one thing.  If you ask
> for zero things?  You get none.

Got it. Thanks for the clarification.

K Jayatheerth· Feb 25, 2026, 00:14 UTC · re: SoutrikDas · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

>> They do not matter plumbing commands intended to be used in scripts.
>> What matters more is being predictable.
> My bad for this ... I did not know about plumbing commands.

In the Pro Git book there is a chapter which has a very good description of plumbing vs porcelain [1]. It might help.

>> And it is more predictable.  If you ask for two things, you get two
>> things.  If you ask for one thing, you get one thing.  If you ask
>> for zero things?  You get none.
> Got it.
> Thanks for the clarification.
[1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

Regards, Jayatheerth

Junio C Hamano· Feb 25, 2026, 02:44 UTC · re: K Jayatheerth · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
Show 19 quoted lines
>>> They do not matter plumbing commands intended to be used in scripts.
>>> What matters more is being predictable.
>
>> My bad for this ... I did not know about plumbing commands.
>
> In the Pro Git book there is a chapter which has a very good description of
> plumbing vs porcelain [1]. It might help.
>
>>> And it is more predictable.  If you ask for two things, you get two
>>> things.  If you ask for one thing, you get one thing.  If you ask
>>> for zero things?  You get none.
>
>> Got it.
>> Thanks for the clarification.
>
> [1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
>
> Regards,
> Jayatheerth
Thanks for clarifying what I left unsaid.  Very much appreciated.
Lucas Seiki Oshiro· Feb 25, 2026, 15:11 UTC · re: K Jayatheerth · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

> In the Pro Git book there is a chapter which has a very good description of
> plumbing vs porcelain [1]. It might help.

Indeed, I also think that the entire "What is Git" and "Git Internals" chapters are worth reading by those who want to contribute to Git.

SoutrikDas· Feb 25, 2026, 15:31 UTC · re: K Jayatheerth · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

> In the Pro Git book there is a chapter which has a very good description of
> plumbing vs porcelain [1]. It might help.
Yup, after reading it I did realise how pointless my suggestion was.
SoutrikDas· Feb 25, 2026, 15:34 UTC · re: Junio C Hamano · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

> Thanks for clarifying what I left unsaid.  Very much appreciated.

Hi, after reading that part I realised how pointless my mail was, so sorry about that.

SoutrikDas· Feb 25, 2026, 15:38 UTC · re: Lucas Seiki Oshiro · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

> Indeed, I also think that the entire "What is Git" and "Git Internals"
> chapters are worth reading by those who want to contribute to Git.
Yeah, that was my bad ... I should have read that before doing anything.
Junio C Hamano· Feb 25, 2026, 15:46 UTC · re: SoutrikDas · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

SoutrikDas <valusoutrik@gmail.com> writes:
>> Thanks for clarifying what I left unsaid.  Very much appreciated.
>
> Hi, after reading that part I realised how pointless my mail was,
> so sorry about that.
No, it wasn't pointless.  It merely was a bit too late.
Thanks for participating.
Kristoffer Haugsbakk· Feb 25, 2026, 15:48 UTC · re: SoutrikDas · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

On Wed, Feb 25, 2026, at 16:34, SoutrikDas wrote:
>> Thanks for clarifying what I left unsaid.  Very much appreciated.
>
> Hi, after reading that part I realised how pointless my mail was,
> so sorry about that.

I didn’t read it as pointless at the time (and not now either). Just perfectly normal back and forth on a patch.

Lucas Seiki Oshiro· Feb 25, 2026, 16:08 UTC · re: SoutrikDas · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

Hi!
> Yup, after reading it I did realise how pointless my suggestion was.

I wouldn't say it was pointless, since you identified something that you thought that could be improved, found the code to be changed and sent a patch proposing your change.

The default behaviour of git-repo-info with no arguments was not a complete consensus at the first place, some people thought it needed to return all the values, and some thought that no value should be returned.

Although in this case I was on the "winner" side (I'm using quotes because I don't think this is a competition), many changes that I did were rejected at first place, and I couldn't see at first what were the problems with them, which I couldn't see only after the reviewing process. The reviewing process is very strict, and it couldn't be different, since Git is used by more than 90% of the developers [2].

Finally, I must say that most things that I think that should do falls under three situations:

1. Git already does that, and I didn't know
2. It was already discussed, and people agreed that Git shouldn't
   do it
3. It's not possible to do that

In your case, it falls in the situation 2 and the discussion, being already discussed [3]. But I understand that it can be frustrating sometimes, and hope you don't feel discouraged in contributing to Git.

[1] 20250610152117.14826-1-lucasseikioshiro@gmail.com [2] https://survey.stackoverflow.co/2022/#version-control-version-control-system-prof [3] 20250915223618.13093-1-lucasseikioshiro@gmail.com

JAYATHEERTH K· Feb 25, 2026, 17:02 UTC · re: SoutrikDas · lore

Re: [RFC RFC PATCH] builtin/repo.c: change info default behavior to show all fields

On Wed, Feb 25, 2026 at 9:04 PM SoutrikDas <valusoutrik@gmail.com> wrote:
Show 5 quoted lines
>
> > Thanks for clarifying what I left unsaid.  Very much appreciated.
>
> Hi, after reading that part I realised how pointless my mail was,
> so sorry about that.

To be honest there is nothing to apologize for In fact that is something I love about the Git community It was a cultural shock for me calling people by their name instead of putting "sir" at the end like they do in India. No one will ask you to say sorry for sending a patch that's for sure.

The list is super active and this will be gone under so many mails that you will forget this existed.

Regards
- Jayatheerth

← back to recent threads