On Mon, Jul 14, 2025 at 08:52:28PM -0300, Lucas Seiki Oshiro wrote:
> Currently, `git rev-parse` covers a wide range of functionality not
> directly related to parsing revisions, as its name says. Over time,
> many features like parsing datestrings, options, paths, and others
> were added to it because there wasn't a more appropriated command
> to place them.
>
> Create a new Git command called `repo`. `git repo` will be the main
> command for obtaining the information about a repository (such as
> metadata and metrics), returning them in a machine readable format
> following the syntax "field<LF>value<NUL>".
>
> Also declare a subcommand for `repo` called `info`. `git repo info`
> will bring the functionality of retrieving repository-related
> information currently returned by `rev-parse`.
>
> Also add entries for this new command in:
>
> - the build files (Makefile, meson.build, Documentation/meson.build)
> - builtin.h
> - git.c
> - .gitignore
> - command-list.txt
> - Documentation
Nit: I don't really think it makes sense to have this bulleted list of
files you have changed unless you provide more context. We basically
already have a way more accurate version of this list 10 lines down in
the diffstat.
> diff --git a/Documentation/git-repo.adoc b/Documentation/git-repo.adoc
> new file mode 100644
> index 0000000000..6f8fe3f6ea
> --- /dev/null
> +++ b/Documentation/git-repo.adoc
> @@ -0,0 +1,54 @@
> +git-repo(1)
> +===========
> +
> +NAME
> +----
> +git-repo - Retrieve information about a repository
> +
> +SYNOPSIS
> +--------
> +[synopsis]
> +git repo info [<key>...]
> +
> +DESCRIPTION
> +-----------
> +Retrieve information about the current repository in a machine-readable format.
> +
> +`git repo` will be the primary tool to query repository-specific information,
I think we should avoid making any promises how this command will evolve
in the future. I'd rather state what it does right now than to say what
it will eventually do.
> +such as metadata that currently can also be done by calling `git rev-parse` (see
> +linkgit:git-rev-parse[1]). `git repo` doesn't query information unrelated to the
> +current repository or that is already retrieved by a specialized command, for
> +example, `git config` (see linkgit:git-config[1]) or `git var` (see
> +linkgit:git-var[1]).
> +
> +This command returns the retrieved data following a null-terminated format with
> +this syntax:
> ++
> +----------------
> +key1<LF>value1<NUL>
> +key2<LF>value2<NUL>
> +...
> +----------------
> ++
One of the things I wonder is whether we should by default adapt those
tools to have human-readable format, e.g. in a way that it can be easily
added to git-bugreport(1). This would teach script authors that want to
use the command to use `git repo info --format=porcelain` right from the
start to have a machine-parseable output, and it would allow us to
iterate on the exact output format.
> diff --git a/builtin/repo.c b/builtin/repo.c
> new file mode 100644
> index 0000000000..a1787a3cc5
> --- /dev/null
> +++ b/builtin/repo.c
> @@ -0,0 +1,38 @@
> +#include "builtin.h"
> +#include "parse-options.h"
> +
> +static int repo_info(int argc UNUSED,
> + const char **argv UNUSED,
> + const char *prefix UNUSED,
> + struct repository *repo UNUSED)
> +{
> + return 0;
> +}
> +
> +int cmd_repo(int argc,
> + const char **argv,
> + const char *prefix,
> + struct repository *repo)
> +{
> + parse_opt_subcommand_fn *fn = NULL;
> + const char *const repo_usage[] = {
> + "git repo info",
> + NULL
> + };
> + struct option options[] = {
> + OPT_SUBCOMMAND("info", &fn, repo_info),
> + OPT_END()
> + };
> +
> + argc = parse_options(argc, argv, prefix, options, repo_usage, 0);
> +
> + if (fn) {
> + return fn(argc, argv, prefix, repo);
> + } else {
> + if (argc) {
> + error(_("unknown subcommand: `%s'"), argv[0]);
> + usage_with_options(repo_usage, options);
> + }
> + return 1;
I think we need to print an error `if (!argc)`, as well. Otherwise the
user wouldn't know why `git repo` without any argumentsdoesn't do
anything.
Patrick
