Re: [RFC PATCH 0/2] Support --verbose in git history

[Patrick Steinhardt <ps@pks.im>]

On Wed, Nov 11, 2026 at 01:57:46PM +0000, Phillip Wood wrote:
> Hi Patrick
> 
> On 11/11/2026 10:46, Patrick Steinhardt wrote:
> > On Tue, Nov 10, 2026 at 12:15:20PM -0500, Ben Knoble wrote:
> > > > Le 10 nov. 2026 à 08:13, Karthik Nayak <karthik.188@gmail.com> a écrit :
> > > > Phillip Wood <phillip.wood123@gmail.com> writes:
> > > > > 
> > > > > Another case where we might not want the diff is scripted editing as it
> > > > > is much easier if the script does not have to worry about the diff
> > > > > getting in the way of its edits. Personally I'd be happy to see this on
> > > > > by default - the history command is marked as experimental so if having
> > > > > it on by default rather than following "commit.verbose" proves to be
> > > > > problematic we can always change it in the future. If we were staring
> > > > > again I'd also make "commit.verbose" on by default as well so maybe I'm
> > > > > biased.
> > > > > 
> > > > I'm on board with this suggestion. Plus, I see 'git history' to be more
> > > > user facing and it's always nicer to have better defaults for users.
> > > > Showing diffs and verbose information seems to be inline with that. We
> > > > could add an option to disable such output for scripts (but that can be
> > > > done later as you suggested).
> > > > <signature.asc>
> > > 
> > > I can live with opt-out as long as I can turn it off via config.
> > 
> > Yeah, agreed. For me there's two important parts, where being able to
> > disable this is the first one. The second part is that we need to make
> > sure that such a format can work for every subcommand of git-history(1)
> > so that we don't have to have multiple different formats for it.
> 
> Can I just check what you mean by "format" please. It is not clear if that
> refers to the option name, or the way the diff is presented in the message
> template (or both?).

Both probably, but what I meant is the output format. So it would need
to be able to cover:

  - Changes to the commit layout (e.g. `git history split`).

  - Changes to the commit order (a future `git history move`).

  - Changes to the commit message.

  - Updates to multiple references.

I don't think we need to have everything implemented in a first
iteration. But the output format should be flexible enough to display
these kinds of changes.

To me it almost feels like what we want is essentially the format used
by git-range-diff(1).

Patrick