git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 4/4] gitk: pass --no-graph to `git log`

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 11, 2022, 20:00 UTC
Message-ID
<xmqqwni19nrd.fsf@gitster.g>
In-Reply-To
<xmqq5yplb46m.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 10 quoted lines
> Alex Henrie <alexhenrie24@gmail.com> writes:
>
>> What if we make log.graph=true also require feature.experimental=true?
>
> No.  feature.experimental is to give people an opt-in opportunity
> for features that we are considering to enable by default.
>
>> The log.graph option would really be a useful feature for people who
>> use Git exclusively from the CLI without any external tools. It seems
>> that the main challenge is how to give others time to adjust.
Let me clarify the first point by stating it a bit differently.
feature.experimental is all about this:
    We have an idea for this new feature.  We made it useful, and
    also made it not to regress the end-user experience for those
    who do not need the new feature, to the best of our ability.
    But there may be use cases we failed to consider while doing
    so.  So let's ask early adopters, who may use Git in contexts
    that are very different from ours, to try testing it out in
    their daily use, to see if there are unexpected glitches.

You do not have to argue how the --graph feature may be useful for character terminal users. We already know it is, otherwise we wouldn't have added it in the first place.

And arguing how --graph feature is useful does not help prove anything, when at the issue is if it is a good idea to allow the log.graph configuration variable to affect (unfortunate) scripts people wrote around "git log", instead of using plumbing commands, negatively. We already know it will hurt to force everybody to update their script to explicitly pass --no-graph on the command line. This series hasn't done any of the "not to regress to the best of our ability" part.

If there were an agreement on the general direction to _forbid_ use of "git log" in scripts, which would require coordinated efforts to help people migrate over time, e.g.

 - improve plumbing by adding features that people piled only on
   "git log" without allowing plumbing users the same over time.
 - perhaps an automated way to convert scripts that use "git log" to
   instead use "git log --no-graph"

to help script writers migrate away from "git log", adding log.graph configuration variable may become very a good idea.

But without such effort starting at the same time and gaining consensus (or already underway), just adding such a variable to break existing scripts would not be a good idea worth asking the early adopters to test. We already know it would break scripts.

Previous: Junio C HamanoNext: Alex Henrie
Message 9 of 13 in “log: fix memory leak if --graph is passed multiple times”
  1. 1/4 log: fix memory leak if --graph is passed multiple timesAlex Henrie, Feb 11, 2022
  2. 2/4 log: add a --no-graph optionAlex Henrie, Feb 11, 2022
  3. Junio C HamanoFeb 11, 2022
  4. Alex HenrieFeb 11, 2022
  5. 4/4 gitk: pass --no-graph to `git log`Alex Henrie, Feb 11, 2022
  6. Junio C HamanoFeb 11, 2022
  7. Alex HenrieFeb 11, 2022
  8. Junio C HamanoFeb 11, 2022
  9. Junio C HamanoFeb 11, 2022
  10. Alex HenrieFeb 11, 2022
  11. Alex HenrieFeb 11, 2022
  12. 3/4 log: add a log.graph config optionAlex Henrie, Feb 11, 2022
  13. Junio C HamanoFeb 11, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.