All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Henrie <alexhenrie24@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git mailing list <git@vger.kernel.org>, paulus@ozlabs.org
Subject: Re: [PATCH 2/3] log: add a config option for --graph
Date: Thu, 10 Feb 2022 09:49:55 -0700	[thread overview]
Message-ID: <CAMMLpeS9MrHdq4bNwDYUJ0ctAafsjLskXStcsO_vBnfngwor-A@mail.gmail.com> (raw)
In-Reply-To: <xmqq4k5799sf.fsf@gitster.g>

On Wed, Feb 9, 2022 at 11:25 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Alex Henrie <alexhenrie24@gmail.com> writes:
>
> > +     if (default_graph &&
> > +         !rev->graph &&
>
> This part I can see why we want to check ;-)
>
> > +         !rev->track_linear &&
> > +         !rev->reverse &&
> > +         !rev->reflog_info &&
> > +         !rev->no_walk) {
>
> But this makes me wonder how we plan to keep this list of "if the
> user asked for any of these options, we shouldn't turn graph on by
> default" up-to-date.  The scheme looks brittle.
>
> Also, what would happen when a developer wants to add, say
> log.reverse, configuration variable in the future?  I can see the
> block to do the equivalent of this for .log.reverse begins with
>
>         if (default_reverse &&
>             !rev->reverse &&
>
> but I am not sure what other conditions need to be checked,
> especially with 'graph'---should it check for !rev->graph or
> default_graph of both?  Are we playing with a potential
> combinatorial explosion?

In principle there's no reason why --graph and --reverse can't be
compatible. However, if both log.graph and log.reverse config options
are added while they are still incompatible, I think using them
together should trigger the existing option compatibility error in the
setup_revisions function:

        if (revs->reverse && revs->graph)
                die(_("options '%s' and '%s' cannot be used
together"), "--reverse", "--graph");

That said, we should make sure that --graph on the command line
overrides log.reverse in the config file (instead of dying), and the
same for --reverse overriding log.graph. How about this:

1. In git_log_config, initialize default_graph and default_reverse by
parsing log.graph and log.reverse.

2. In cmd_log_init_defaults, initialize rev->graph_default to
default_graph and rev->reverse_default to default_reverse.

3. In handle_revision_opt, set revs->graph if --graph is given, clear
revs->graph if --no-graph is given, and in either case clear
revs->graph_default. Set revs->reverse and revs->reverse_default
likewise.

4. In setup_revisions, if revs->graph_default is still true, set
revs->graph based on revs->reverse and revs->reverse_default. Set
revs->reverse likewise.

5. In setup_revisions, call a new revision_opts_finish function that
sets revs->topo_order and revs->rewrite_parents if necessary based on
the final value of revs->graph.

I think that would ensure that command line options interact correctly
with config options, plus it would allow adding a --no-graph command
line option, and the logic to handle defaults would be clearly linked
to the existing incompatible option checks. I realize that it will
take a bit of refactoring though. I'll send new patches shortly to
make it more clear.

Please let me know if any of your other feedback is still relevant in v2.

-Alex

  reply	other threads:[~2022-02-10 16:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09 16:23 [PATCH 1/3] log: fix memory leak if --graph is passed multiple times Alex Henrie
2022-02-09 16:23 ` [PATCH 2/3] log: add a config option for --graph Alex Henrie
2022-02-09 18:25   ` Junio C Hamano
2022-02-10 16:49     ` Alex Henrie [this message]
2022-02-09 16:23 ` [PATCH 3/3] gitk: set log.graph=false when running `git log` Alex Henrie
2022-02-09 18:26   ` Junio C Hamano
2022-02-10 16:50     ` Alex Henrie
2022-02-10 20:15       ` Junio C Hamano
2022-02-09 18:16 ` [PATCH 1/3] 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

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

  git send-email \
    --in-reply-to=CAMMLpeS9MrHdq4bNwDYUJ0ctAafsjLskXStcsO_vBnfngwor-A@mail.gmail.com \
    --to=alexhenrie24@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.