Re: [RFC PATCH] log: add log.showStat configuration variable

[Derrick Stolee <stolee@gmail.com>]

On 10/11/2020 5:59 AM, Robert Karszniewicz wrote:
> On Thu, Oct 08, 2020 at 02:12:50PM -0400, Derrick Stolee wrote:
>> On 10/8/2020 12:20 PM, Robert Karszniewicz wrote:
>>> Changes default behaviour of `git log` and `git show` when no
>>> command-line options are given. Doesn't affect behaviour otherwise (same
>>> behaviour as with stash.showStat).
>>> ---
>>> I've wanted to have `show` and `log` show --stat by default, and I
>>> couldn't find any better solution for it. And I've discovered that there
>>> is stash.showStat, which is exactly what I want. So I wanted to bring
>>> stash.showStat to `show` and `log`.
>>
>> I'm wondering: why should this be a config setting instead of just
>> a configure alias?
> 
> I answered this in the reply to Junio C Hamano.
> 
> Actually, the first thing I tried, was make an alias named after the git
> command, like so:
> 
>   git config --global alias.show "show --stat"
>   git config --global alias.log "log --stat"
> 
> But that didn't work. Why, actually? We're used to it from our POSIX
> shells, and other places I can't think of, but it feels familiar.
> Perhaps this would be a good way to enable changing default behaviour of
> each git command without having to change anything about config
> handling? Would this be difficult to do?

You can't replace a builtin with an alias, because that creates a
recursive loop. Note that I changed the name to "slog" for my example.

If you are going to customize it, then you need to remember your new
name. But this is something you can do right now without needing to
patch Git.

>> If this is something we want to do as a config instead of alias,
>> I'm wondering if it is worth expanding the scope and thinking about
>> these other arguments (like --graph, --oneline, etc.) and how they
>> could be incorporated into a coherent config system.
>>
>> I worry that this initial step leads us down a road of slowly adding
>> one-off config settings for each option when:
> 
> I worried about that, too. But I think the initial step was already in
> 2015, when stash.showStat and stash.showPatch were added. No flood of
> options happened since then? I was actually surprised about it, too,
> that it took so long until someone wanted to have showStat for show and
> log, too.

I'm not sure these examples will help your case.

Does 'stash' have more things that would be beneficial to show
every time? If no, then 'stash' is much more specialized than
'show' and 'log' which have many more options. If yes, then this
is exactly what we want to avoid happening: an incomplete set of
config options that are tailored to a small subset of options.

While my stance is still "an alias should suffice," perhaps it is
worth investigating the "status.*" config options, which include
this kind of behavior:

* status.aheadBehind can disable some output normally there by
  default. (This was created for performance implications.)

* status.showStash enables --show-stash

* status.showUntrackedFiles enables --untracked-files

* status.submoduleSummary interacts with --ignore-submodules

Thanks,
-Stolee