All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] diff-merges: cleanup set_diff_merges()
Date: Thu, 15 Sep 2022 13:41:17 -0700	[thread overview]
Message-ID: <xmqq35csmkuq.fsf@gitster.g> (raw)
In-Reply-To: <20220914193102.5275-3-sorganov@gmail.com> (Sergey Organov's message of "Wed, 14 Sep 2022 22:31:01 +0300")

Sergey Organov <sorganov@gmail.com> writes:

> Get rid of special-casing of 'suppress' in set_diff_merges(). Instead
> set 'merges_need_diff' flag correctly in every option handling
> function.
>
> Signed-off-by: Sergey Organov <sorganov@gmail.com>
> ---
>  diff-merges.c | 30 +++++++++++++++++++-----------
>  1 file changed, 19 insertions(+), 11 deletions(-)

Looks OK to me.

Everybody else says set_X() but set_none() has nothing to do ther
than calling suppress(), so the change does not really make a
functional difference (as you said in the cover letter).

Is the idea that the original value in .merges_need_diff member does
not matter because in every case it is set to either 0 or 1?  Most
cases call common_setup() to set it to 1 like this here...

> +static void common_setup(struct rev_info *revs)
> +{
> +	suppress(revs);
> +	revs->merges_need_diff = 1;
> +}

... but this does not touch (in other words, it does not explicitly
clear) it, ...

> +static void set_none(struct rev_info *revs)
> +{
> +	suppress(revs);
> +}

 ... so we still rely on somebody to set the .merges_need_diff
to 0 initially, right?

> -
> -	/* NOTE: the merges_need_diff flag is cleared by func() call */
> -	if (func != suppress)
> -		revs->merges_need_diff = 1;
>  }

It is very good to see this one go.

>  /*
> @@ -115,6 +122,7 @@ int diff_merges_parse_opts(struct rev_info *revs, const char **argv)
>  
>  	if (!suppress_m_parsing && !strcmp(arg, "-m")) {
>  		set_to_default(revs);
> +		revs->merges_need_diff = 0;

I am wondering how this becomes necessary?  Is it because
set_to_default() would flip the member to 1 unconditionally, or
something?  If it weren't for this hunk, the lossage of the previous
hunk is a very good clean-up, but if we need to do this, I cannot
shake the feeling that we mostly shifted the dirt around, without
really cleaning it?  I dunno.

> @@ -125,7 +133,7 @@ int diff_merges_parse_opts(struct rev_info *revs, const char **argv)
>  		set_remerge_diff(revs);
>  		revs->merges_imply_patch = 1;
>  	} else if (!strcmp(arg, "--no-diff-merges")) {
> -		suppress(revs);
> +		set_none(revs);

We do not need to explicitly set .merges_need_diff to 0 here,
presumably because it is initialized to 0 and nobody touched it,
right?

>  	} else if (!strcmp(arg, "--combined-all-paths")) {
>  		revs->combined_all_paths = 1;
>  	} else if ((argcount = parse_long_opt("diff-merges", argv, &optarg))) {
> @@ -139,7 +147,7 @@ int diff_merges_parse_opts(struct rev_info *revs, const char **argv)
>  
>  void diff_merges_suppress(struct rev_info *revs)
>  {
> -	suppress(revs);
> +	set_none(revs);
>  }
>  
>  void diff_merges_default_to_first_parent(struct rev_info *revs)

  reply	other threads:[~2022-09-15 20:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-14 19:30 [PATCH 0/3] diff-merges: minor cleanups Sergey Organov
2022-09-14 19:31 ` [PATCH 1/3] diff-merges: cleanup func_by_opt() Sergey Organov
2022-09-15 18:47   ` Junio C Hamano
2022-09-16 13:01     ` Sergey Organov
2022-09-16 16:14       ` Junio C Hamano
2022-09-16 16:28         ` Sergey Organov
2022-09-14 19:31 ` [PATCH 2/3] diff-merges: cleanup set_diff_merges() Sergey Organov
2022-09-15 20:41   ` Junio C Hamano [this message]
2022-09-16 13:38     ` Sergey Organov
2022-09-14 19:31 ` [PATCH 3/3] diff-merges: clarify log.diffMerges documentation Sergey Organov
2022-09-15 18:43   ` Junio C Hamano
2022-09-16 13:46     ` Sergey Organov
2022-09-16 16:21       ` 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=xmqq35csmkuq.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sorganov@gmail.com \
    /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.