Re: [PATCH v9 6/7] builtin: add new "history" command

> On Fri, Jan 9, 2026 at 12:35 AM Patrick Steinhardt <ps@pks.im> wrote:
> > diff --git a/Documentation/git-history.adoc b/Documentation/git-history.adoc
> > new file mode 100644
> > index 0000000000..5a9d931efc
> > --- /dev/null
> > +++ b/Documentation/git-history.adoc
> > @@ -0,0 +1,56 @@
> > +git-history(1)
> > +==============
> > +
> > +NAME
> > +----
> > +git-history - EXPERIMENTAL: Rewrite history
> > +
> > +SYNOPSIS
> > +--------
> > +[synopsis]
> > +git history [<options>]
> > +
> > +DESCRIPTION
> > +-----------
> > +
> > +Rewrite history by rearranging or modifying specific commits in the
> > +history.
> > +
> > +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> > +
> > +This command is related to linkgit:git-rebase[1] in that both commands can be
> > +used to rewrite history. There are a couple of major differences though:
> > +
> > +* linkgit:git-history[1] can work in a bare repository as it does not need to
> > +  touch either the index or the worktree.
> > +* linkgit:git-history[1] does not execute any linkgit:githooks[5] at the
> > +  current point in time. This may change in the future.
> > +* linkgit:git-history[1] by default updates all branches that are descendants
> > +  of the original commit to point to the rewritten commit.
> > +
> > +Overall, linkgit:git-history[1] aims to provide a more opinionated way to modify
> > +your commit history that is simpler to use compared to linkgit:git-rebase[1] in
> > +general.
> > +
> > +If you want to reapply a range of commits onto a different base, or interactive
> > +rebases if you want to edit a range of commits.
> 
> "If ..." with no "then ..." ?  This sentence isn't complete.

> > diff --git a/builtin/history.c b/builtin/history.c
> > new file mode 100644
> > index 0000000000..f6fe32610b
> > --- /dev/null
> > +++ b/builtin/history.c
> > @@ -0,0 +1,22 @@
> > +#include "builtin.h"
> > +#include "gettext.h"
> > +#include "parse-options.h"
> > +
> > +int cmd_history(int argc,
> > +               const char **argv,
> > +               const char *prefix,
> > +               struct repository *repo UNUSED)
> > +{
> > +       const char * const usage[] = {
> > +               N_("git history [<options>]"),
> > +               NULL,
> > +       };
> > +       struct option options[] = {
> > +               OPT_END(),
> > +       };
> > +
> > +       argc = parse_options(argc, argv, prefix, options, usage, 0);
> > +       if (argc)
> > +               usagef("unrecognized argument: %s", argv[0]);
> 
> Oh, the manual is just a placeholder that you'll extend later?  That
> makes sense, but it would be less confusing if it started out with "No
> subcommands are yet supported, but will be added later", with that
> sentence removed in the next commit when you add a subcommand.