Re: [PATCH 1/2] builtin/commit: error out when passing untracked path with -i
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 18, 2024, 17:27 UTC
- Message-ID
- <xmqqedc7h2le.fsf@gitster.g>
- In-Reply-To
- <20240318155219.494206-4-shyamthakkar001@gmail.com>
Ghanshyam Thakkar <shyamthakkar001@gmail.com> writes:
Show 7 quoted lines
> 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.
Show 36 quoted lines
> [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.