git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Henrie <alexhenrie24@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>, paulus@ozlabs.org
Subject: Re: [PATCH v3 4/4] gitk: pass --no-graph to `git log`
Date: Fri, 11 Feb 2022 12:00:54 -0800	[thread overview]
Message-ID: <xmqqwni19nrd.fsf@gitster.g> (raw)
In-Reply-To: <xmqq5yplb46m.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 11 Feb 2022 11:20:49 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> 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.

  reply	other threads:[~2022-02-11 20:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11 16:36 [PATCH v3 1/4] log: fix memory leak if --graph is passed multiple times Alex Henrie
2022-02-11 16:36 ` [PATCH v3 2/4] log: add a --no-graph option Alex Henrie
2022-02-11 19:02   ` Junio C Hamano
2022-02-11 19:20     ` Alex Henrie
2022-02-11 16:36 ` [PATCH v3 3/4] log: add a log.graph config option Alex Henrie
2022-02-11 16:36 ` [PATCH v3 4/4] gitk: pass --no-graph to `git log` Alex Henrie
2022-02-11 18:12   ` Junio C Hamano
2022-02-11 19:05     ` Alex Henrie
2022-02-11 19:20       ` Junio C Hamano
2022-02-11 20:00         ` Junio C Hamano [this message]
2022-02-11 20:11           ` Alex Henrie
2022-02-11 20:08         ` Alex Henrie
2022-02-11 18:51 ` [PATCH v3 1/4] log: fix memory leak if --graph is passed multiple times Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqwni19nrd.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=alexhenrie24@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=paulus@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).