Missing git options

Hi there,

I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.

This seems something that should be relatively easy to fix.

What I’m most missing is

— snip —
[log]
	graph = true
	patch = true
— snap —

which would / should correspond to `git log —graph —patch`.

What do you guys think?

Best Regards,
Martin Häcker

On Mon, Feb 5, 2018 at 1:12 AM, Martin Häcker
[off-list ref] wrote:

Hi there,

I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.

This seems something that should be relatively easy to fix.

What I’m most missing is

— snip —
[log]
        graph = true
        patch = true
— snap —

which would / should correspond to `git log —graph —patch`.

What do you guys think?

Feel free to send patches adding these options.

I had the impression that git-log was a pseudo-plumbing,
despite it being explicitly marked porcelain
as there is no good plumbing alternative.
But as we already have things like log.date, log.decorate,
that change the output of git-log, I think a patch or graph
option would be ok.

Thanks,
Stefan

On Mon, Feb 05 2018, Martin Häcker jotted:

Hi there,

I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.

This seems something that should be relatively easy to fix.

What I’m most missing is

— snip —
[log]
	graph = true
	patch = true
— snap —

which would / should correspond to `git log —graph —patch`.

What do you guys think?

FWIW my WIP
https://public-inbox.org/git/20170328131316.32516-1-avarab@gmail.com/
had some discussion around this.

On Mon, Feb 05, 2018 at 10:12:05AM +0100, Martin Häcker wrote:

Hi there,

I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration.

This seems something that should be relatively easy to fix.

What I’m most missing is

— snip —
[log]
	graph = true
	patch = true
— snap —

which would / should correspond to `git log —graph —patch`.

What do you guys think?

I think this is likely to cause problems.  Many people use git log with
--pretty to format commit hashes or messages into other programs.  I'm
aware of multiple tools that will simply break if --graph or --patch
become the default.  Requiring people to retrofit their tools to use
--no-graph or --no-patch is likely to be a burden.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

Hi all,

Am 06.02.2018 um 01:43 schrieb brian m. carlson [off-list ref]:

I think this is likely to cause problems.  Many people use git log with
--pretty to format commit hashes or messages into other programs.  I'm
aware of multiple tools that will simply break if --graph or --patch
become the default.  Requiring people to retrofit their tools to use
--no-graph or --no-patch is likely to be a burden.

While I share your concern, this is something that will completely freeze development of the git tui which I cannot imagine is wanted.

If this where my tool, I would much rather advertise an output format specifically for scripting.

An interim solution could be something like an `—ignore-configuration` option that allows script writers to get predictable output. This however still freezes the default output of git forever.

So you will need something like —output-for=scripting|json|xml|whatever sooner or later. Mixing up the TUI for humans and for scripts is not going to be fun to evolve.

Best Regards,
Martin Häcker

On Tue, Feb 6, 2018 at 6:13 PM, Martin Häcker
[off-list ref] wrote:

This however still freezes the default output of git forever.

Why is that a bad thing? Default output format should not change
(much) from version to version, or from machine to machine (because of
different ~/.gitconfig) for that matter. I don't want to type "git
log" on somebody else's machine and have a big surprise. You _can_
customize output but that should be explicit.

If you want good defaults, that's what aliases are for. I personally
rarely type "git log". I have "l", "lp", "l1"  and other aliases for
my everyday use.
-- 
Duy

Hi,

Martin Häcker wrote:

quoted

Am 06.02.2018 um 01:43 schrieb brian m. carlson [off-list ref]:

quoted

I think this is likely to cause problems.  Many people use git log with
--pretty to format commit hashes or messages into other programs.  I'm
aware of multiple tools that will simply break if --graph or --patch
become the default.  Requiring people to retrofit their tools to use
--no-graph or --no-patch is likely to be a burden.

While I share your concern, this is something that will completely
freeze development of the git tui which I cannot imagine is wanted.

On the contrary, we take things on a case by case basis.  Brian
described a cost to your proposed change and you described a benefit;
the next step would be to figure out a way to accomplish what you're
aiming to do in a way that maximizes the benefit and minimizes the
cost.

In other words, it is not that we never change default output formats,
but we do care a lot about helping existing users.  One way of doing
that is to provide more convenient machine-readable versions of some
commands so that it is obvious to script writers what to use.

As Stefan Beller mentioned, "git log" is in interesting case, in that
the scripting commands exist:

 - "git rev-list" to list commits satisfying some criteria
 - "git diff-tree --stdin" to show information about those commits

But these commands were not sufficiently discoverable and easy to use,
so people end up using "git log" for scripting anyway.  We provide

 - "git log --format" to produce log output with a fixed format, and
   in particular

 - "git log --format=raw" to print raw objects

It's perfectly normal and common to change what "git log
--format=medium" (the default format) prints, as long as we take into
account the effect on existing users.  In particular:

 - Some scripts do not care about the *exact* format from "git log"
   but are using the output for a particular purpose (e.g. to generate
   release notes that they distribute along with compiler output).
   If these scripts start _sometimes_ using --graph instead based on
   configuration, this would be disruptive to some users.

 - Making --format suppress `log.graph` configuration feels confusing
   and hard to explain to me.  --graph --format=<x> would mean something
   different from -c log.graph=true --format=<x>, except when <x> =
   medium, or "--format=medium" would mean something different from not

19 more lines