git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Sangeeta NB <sangunb09@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Kaartic Sivaraam <kaartic.sivaraam@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [Outreachy] [PATCH v3] diff: do not show submodule with untracked files as "-dirty"
Date: Fri, 23 Oct 2020 08:19:35 -0700	[thread overview]
Message-ID: <xmqqr1pphsvs.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAHjREB4qGO1=XCy-F+H39FP_KU_zZjKCDA=b9JxCe0WZdM06KQ@mail.gmail.com> (Sangeeta NB's message of "Fri, 23 Oct 2020 10:53:19 +0530")

Sangeeta NB <sangunb09@gmail.com> writes:

> Sorry for sending it over and over again. I couldn't figure out why
> the mail is not reaching the community.

FWIW, I'm seeing it for the first time, so no worries ;)

>> This new boolean is meant to be set only when non-default
>> ignore-submodules option is given either from the command line or
>> from the configuration---when the bit is unset, we are told to do
>> whatever it is that is the default for us.
>
> I fear I might not get your question clearly here. But from what I
> understood this boolean( flags.ignore_submodule_set )  is set only
> when diff.ignoreSubmodules is set in user-config.

The four-line paragraph I wrote above is not a question.  It is
normal to "think aloud" to express what the reader understood what
the patch does/intends to do during the review, which gives the
contributor a chance to spot misunderstanding by the reviewer.

In any case, when "git diff --ignore-submodules=<when>" command line
option is parsed, diff_opt_ignore_submodules() gets called, which in
turn calls handle_ignore_submodules_arg(), and you set the bit
there.

So this is not limited to configuration, I think.  Command line
option given by the user can also affect it.

Moreover, wt-status.c:wt_status_collect_changes_index() hardcodes
a call to handle_ignore_submodules_arg() with hardcoded "dirty"
unless the caller specifies s->ignore_submodule_arg.  This is not
even user-config or any user action---it is more like a hardcoded
default.

>> And the default is to flip only this bit on.  Do we need to turn off
>> other bits that submodule.c::handle_ignore_submodules_arg() function
>> touches?  [*1*]
>>
>
> We are not flipping the bit, we are setting it to 1.

Yeah, flipping it to on is setting it to 1.  We are saying the same
thing, aren't we?

> I guess we don't
> have to turn off other bits because in case if
> submodule.c::handle_ignore_submodules_arg() is called we don't have to
> set the default value.
>
> So there's no point in flipping any other bits
> as if any of them is set, the user should have added some arguments in
>  ignoreSubmodules and therefore flags.ignore_submodule_set would be
> set to 1 and we won't be setting the default value.

The reason why a helper function handle_ignore_submodules_arg()
exists in the first place is because the way ignore_* bits are
managed in the diff_options.flags is tricky and with a helper in
between the callers and the actual bits, is easier to update in the
future if needed.

So even if we assume that everybody who reacted to end-user
preference would have called handle_ignore_submodules_arg(), hence
we do not want to force our default when the .ignore_submodule_set
bit set and we do want to do so when the bit is unset, we should
do

	if (!options->flags.ignore_submodule_set)
		handle_ignore_submodules_arg("untracked");

instead of only toggling the .ignore_untracked_in_submodules bit on
manually.

>> I like the general idea of having one bit that is set if and only if
>> the command line or configuration told us specifically what to do,
>> so that we can dictate the default after they were taken care of.
>> ...
>> Even without anticipating such a change in the future, there already
>> is a callsite of this function in wt-status.c that hands a hardcoded
>> string "dirty" to it.  That is *not* caused by an end-user request
>> (be it a configuration variable or a command line option), so in a
>> sense, the assumption is already broken.
>
> I couldn't fully understand what assumption are you talking about. I
> would be glad if you can explain it to me in a little more detail.

Have you looked for "dirty" (with double-quote around the word) in
wt-status.c already?  The call to handle_ignore_submodules_arg(),
which would cause your new bit set, is made not as a reaction to any
end-user input.  Rather it is "if end-user did not say anything, use
this hardcoded setting".  And it overrides the "if the end user did
not specify anything, we want to use this default" logic you added
with this change, because it dictates "dirty" there without end-user
asking.

Is that desirable?  I dunno.

>> Noise.
>>
> I hope this is a substitute for nice. XD. Hearing this after a long
> time. I used to hear this more frequently when I was in college.

I found this change a "noise":

 	strvec_pushl(&cp.args, "status", "--porcelain=2", NULL);
 	if (ignore_untracked)
-		strvec_push(&cp.args, "-uno");
+		strvec_push (&cp.args, "-uno");

If it were going the other direction, "we fix coding style violation
while at it" may be a good justification to do so, but this
particular change (1) is not neeeded for the purpose of this patch,
and (2) is making the code worse by deviating from the coding
guideline.  Please drop it.

Thanks.

  reply	other threads:[~2020-10-23 15:19 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 17:08 [PATCH] diff: do not show submodule with untracked files as "-dirty" Sangeeta via GitGitGadget
2020-10-20 13:38 ` [OUTREACHY][PATCH] " Phillip Wood
2020-10-20 18:10   ` Sangeeta NB
2020-10-21 11:28     ` Phillip Wood
2020-10-21 13:10 ` [Outreachy] [PATCH v2] " Sangeeta Jain
2020-10-21 17:43   ` Eric Sunshine
2020-10-21 19:40     ` Sangeeta NB
2020-10-21 23:04       ` Eric Sunshine
2020-10-22 11:22 ` [Outreachy] [PATCH v3] " Sangeeta Jain
2020-10-22 18:07   ` Junio C Hamano
2020-10-23  5:23     ` Sangeeta NB
2020-10-23 15:19       ` Junio C Hamano [this message]
2020-10-23 18:17         ` Sangeeta NB
2020-10-23 18:55           ` Junio C Hamano
2020-10-23 19:08             ` Sangeeta NB
2020-10-23 11:17 ` [PATCH v4] " Sangeeta Jain
2020-10-23 15:56   ` Junio C Hamano
2020-10-23 18:32     ` Sangeeta NB
2020-10-23 20:22       ` Junio C Hamano
2020-10-23 11:18 ` [Outreachy] " Sangeeta Jain
2020-10-23 21:28   ` Junio C Hamano
2020-10-25 10:23     ` Sangeeta NB
2020-10-26 17:36       ` Junio C Hamano
2020-10-23 19:29 ` [Outreachy] [PATCH v5] " Sangeeta Jain
2020-10-26 17:57 ` [Outreachy][PATCH v6] " Sangeeta Jain
2020-11-03 10:46   ` Sangeeta
2020-11-03 17:55     ` Junio C Hamano
2020-11-07 10:47       ` Sangeeta
2020-12-08 21:02         ` Junio C Hamano
2020-11-07 11:10   ` Đoàn Trần Công Danh
2020-11-09 15:19     ` Sangeeta
2020-11-09 17:01       ` Junio C Hamano
2020-11-10  8:39 ` [Outreachy][PATCH v7] " Sangeeta Jain
2020-11-10 17:09   ` Đoàn Trần Công Danh
2020-12-08 13:36   ` Sangeeta
2020-12-08 22:26     ` 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=xmqqr1pphsvs.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kaartic.sivaraam@gmail.com \
    --cc=phillip.wood123@gmail.com \
    --cc=sangunb09@gmail.com \
    --cc=sunshine@sunshineco.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.
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).