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

[Patrick Steinhardt <ps@pks.im>]

On Wed, Nov 11, 2026 at 10:39:51AM -0500, Ben Knoble wrote:
> 
> > Le 11 nov. 2026 à 09:03, Patrick Steinhardt <ps@pks.im> a écrit :
> > 
> > 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
> 
> Interesting; I certainly would appreciate range-diff-like content *somewhere*
> when using git-history. The original proposal was more like commit’s
> verbose diff in the editor, though, and I can see a desire to have that
> in all of the supported subcommands, too (maybe just as a reminder).

Oh, right. Shouldn't be posting on the mailing with a headache, I guess.

Patrick