Re: [Outreachy][PATCH v6] diff: do not show submodule with untracked files as "-dirty"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 8, 2020, 21:02 UTC
- Message-ID
- <xmqqblf46mg8.fsf@gitster.c.googlers.com>
- In-Reply-To
- <CAHjREB7-QWHBOQQPdDdEM-gJm=w3+4D=N=5TaS3UE__6XnSpJA@mail.gmail.com>
Sangeeta <sangunb09@gmail.com> writes:
Show 42 quoted lines
> Hey,
>
> I worked on passing --ignore-submodules=none as the default behavior
> of git status so that the user doesn't end up deleting a submodule
> that has uncommitted (untracked) files.
>
> The following changes make git status pass the ignoreSubmodules none
> argument as default.
>
> @@ -4587,7 +4587,7 @@ void repo_diff_setup(struct repository *r,
> struct diff_options *options)
> options->orderfile = diff_order_file_cfg;
>
> if (!options->flags.ignore_submodule_set)
> - handle_ignore_submodules_arg(options, "untracked");
> + options->flags.ignore_untracked_in_submodules = 1;
>
> if (diff_no_prefix) {
> options->a_prefix = options->b_prefix = "";
>
>
> @@ -607,6 +607,9 @@ static void
> wt_status_collect_changes_worktree(struct wt_status *s)
> rev.diffopt.flags.override_submodule_config = 1;
> handle_ignore_submodules_arg(&rev.diffopt,
> s->ignore_submodule_arg);
> }
> + else if(!rev.diffopt.flags.ignore_submodule_set){
> + handle_ignore_submodules_arg(&rev.diffopt, "none");
> + }
>
> I have had to set the flag manually in diff.c because when we call
> handle_ignore_submodules_arg() with "untracked" arg,
> options->flags.ignore_submodule_set is set to 1 and therefore when we
> check for it in wt-status.c it appears that user has already set some
> config and therefore we shouldn't add "none" as ignoreSubmodules arg.
>
> Another way to do that is to have one more flag in diff_options that
> can let us know whether options->flags.ignore_submodule_set was set by
> the user or by diff passing untracked as the default argument.
>
> Can someone please help me with what might be the right way to proceed?Hmph, neither sounds "right"---having to circumvent the assignment to _set flag made in the handle_ helper by either manually setting the underlying flag, or by introducing another flag that stops from the _set flag getting updated, sounds like working around a flaw of the approach to use _set flag and set it in the handle_ helper in the first place...