Re: [PATCH 1/2] builtin/commit: error out when passing untracked path with -i

[Junio C Hamano <gitster@pobox.com>]

Ghanshyam Thakkar <shyamthakkar001@gmail.com> writes:

> Currently when we provide a pathspec which does not match any tracked
> path alongside --include, we do not error like without --include. If
> there is something staged, it will commit the staged changes and ignore
> the pathspec which does not match any tracked path. And if nothing is
> staged, it will print the status. Exit code is 0 in both cases (unlike
> without --include). This was also described in the TODO comment before
> the relevant testcase.

Drop "currently" (cf. https://lore.kernel.org/git/xmqqle6xbep5.fsf@gitster.g/)

> Fix this by matching the pathspec against index and report error if
> any. And amend the relevant testcase and remove the TODO comment.

> [RFC]: I am still unsure about the removal of --include related lines
> from the testcase which checks whether the index is expanded or not from
> t1092. Will separating it into a separate testcase of its own and
> marking that to expect failure be better?
>
>  builtin/commit.c                         | 15 +++++++++++++++
>  t/t1092-sparse-checkout-compatibility.sh |  4 ----
>  t/t7501-commit-basic-functionality.sh    | 16 +---------------
>  3 files changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index a91197245f..f8f5909673 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -441,6 +441,21 @@ static const char *prepare_index(const char **argv, const char *prefix,
>  	 * (B) on failure, rollback the real index.
>  	 */
>  	if (all || (also && pathspec.nr)) {
> +		if (!all) {
> +			int i, ret;
> +			char *ps_matched = xcalloc(pathspec.nr, 1);
> +
> +			/* TODO: audit for interaction with sparse-index. */
> +			ensure_full_index(&the_index);
> +			for (i = 0; i < the_index.cache_nr; i++)
> +				ce_path_match(&the_index, the_index.cache[i],
> +					      &pathspec, ps_matched);
> +
> +			ret = report_path_error(ps_matched, &pathspec);
> +			free(ps_matched);
> +			if (ret)
> +				exit(1);
> +		}
>  		repo_hold_locked_index(the_repository, &index_lock,
>  				       LOCK_DIE_ON_ERROR);
>  		add_files_to_cache(the_repository, also ? prefix : NULL,

"git grep" for report_path_error() gives me four or five hits but
they way all of them populate ps_matched array are different [*],
so we cannot have a helper function to do so.

    Side note: They tend to do "looping over all the paths, see with
    ce_path_match() if the path matches, and do something with that
    path if it does".  They do not do a separate useless loop that
    is only for checking if all the pathspec elements match, like
    the loop in this patch does.

In a sense, not making this into a helper function is the right
thing to do.  It would avoid encouraging this anti-pattern of adding
a separate and otherwise useless loop.

We must already be using pathspec elements to decide to do the
"include" addition among all paths that we know about in some loop
separately, no?  Isn't that what the call to add_files_to_cache() we
see in the post-context doing?  Shouldn't that loop (probably the
one in diff-lib.c:run_diff_files(), that calls ce_path_match() for
each and every path we know about) be the one who needs to learn to
optionally collect the ps_matched information in addition to what it
is already doing?

Thanks.