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

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

[SoutrikDas]

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] : 
>> 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 

> 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.

> 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(+)

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

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

[SoutrikDas]

>  	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(-)

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

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

[Junio C Hamano]

SoutrikDas <valusoutrik@gmail.com> writes:

>> 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...?

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

[SoutrikDas]

> 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.

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

[K Jayatheerth]

>> 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

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

[Junio C Hamano]

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:

>>> 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.

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

[SoutrikDas]

> 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.

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

[Junio C Hamano]

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.

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

[Kristoffer Haugsbakk]

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.

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

[JAYATHEERTH K]

On Wed, Feb 25, 2026 at 9:04 PM SoutrikDas <valusoutrik@gmail.com> 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.


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

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

[Lucas Seiki Oshiro]

> 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.

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

[SoutrikDas]

> 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.

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

[SoutrikDas]

> 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.

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

[Lucas Seiki Oshiro]

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