git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3] submodule: prevent overwriting .gitmodules entry on path reuse
Date: Wed, 14 May 2025 15:47:59 -0700	[thread overview]
Message-ID: <xmqqplga6c80.fsf@gitster.g> (raw)
In-Reply-To: <20250514020108.24396-1-jayatheerthkulkarni2005@gmail.com> (K. Jayatheerth's message of "Wed, 14 May 2025 07:31:08 +0530")

K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:

> Add helper `submodule_active_matches_path()` so we can
> re-implement the old “is this path already covered by
> submodule.active?” logic without re-reading the config twice.

Having duplicated code to implement what is supposed to be the same
thing is a bug waiting to happen by them diverging from each other.

Isn't the fact that our configuration reading code reads things just
once and the caches the result good enough for the purpose of this
code path?  Do we have a measurement that tells us that the extra
complexity is worth the maintenance headache?

> @@ -3443,7 +3452,11 @@ static int module_add(int argc, const char **argv, const char *prefix,
>  	int force = 0, quiet = 0, progress = 0, dissociate = 0;
>  	struct add_data add_data = ADD_DATA_INIT;
>  	const char *ref_storage_format = NULL;
> +	const struct submodule *existing;
>  	char *to_free = NULL;
> +	struct strbuf buf = STRBUF_INIT;
> +	int i;
> +	int allocated_sm_name = 0;

A separate flag is not wrong per-se, but the idiom used in this
project more often is to have an extra pointer variable that points
at an allocated piece of memory (or NULL), and free the piece of
memory unconditionally.

"git grep -e to_free" to see the idiom in action.  Even better yet,
this codepath already uses the idiom.

By doing so

> +	if (allocated_sm_name)
> +		free((char *)add_data.sm_name);

becomes

	free(sm_name_to_free);

and we can keep the "add_data.sm_name is pointing at a borrowed
piece of memory, and we will _never_ free anything through that
pointer" memory ownership rule.  We were borrowing from a separate
variable sm_name_to_free, and we may free it when add_data is
getting destroyed, or we may be borrowing from the .sm_path string,
which we would free it when add_data is getting destroyed.

>  	free(add_data.sm_path);
>  	free(to_free);
>  	strbuf_release(&sb);
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index d6a501d453..5c3f471338 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -1482,4 +1482,27 @@ test_expect_success '`submodule init` and `init.templateDir`' '
>  	)
>  '
>  
> +test_expect_success 'submodule add fails when name is reused' '
> +	git init test-submodule &&
> +	(
> +		cd test-submodule &&
> +		git commit --allow-empty -m "initial commit" &&
> +
> +		git init ../child-origin &&
> +		git -C ../child-origin commit --allow-empty -m "initial commit" &&
> +
> +		git submodule add ../child-origin child &&
> +		git commit -m "Add submodule child" &&
> +
> +		git mv child child_old &&
> +		git commit -m "Move child to child_old" &&
> +
> +		# Create another submodule repo
> +		git init ../child2-origin &&
> +		git -C ../child2-origin commit --allow-empty -m "initial commit" &&
> +
> +		test_must_fail git submodule add ../child2-origin child
> +	)
> +'
> +
>  test_done

  reply	other threads:[~2025-05-14 22:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-10  5:45 [PATCH] submodule: prevent overwriting .gitmodules entry on path reuse K Jayatheerth
2025-05-10  5:57 ` JAYATHEERTH K
2025-05-12 12:32 ` Junio C Hamano
2025-05-12 13:26   ` JAYATHEERTH K
2025-05-13  3:34     ` [PATCH v2] " K Jayatheerth
2025-05-13 21:44       ` Junio C Hamano
2025-05-14  2:01         ` [PATCH v3] " K Jayatheerth
2025-05-14 22:47           ` Junio C Hamano [this message]
2025-05-16  8:51             ` JAYATHEERTH K
2025-05-16 17:49               ` [PATCH v4] " K Jayatheerth
2025-05-16 17:53                 ` JAYATHEERTH K
2025-05-18  7:54                   ` [PATCH v5] " K Jayatheerth
2025-05-18  7:58                     ` JAYATHEERTH K
2025-05-19 15:41                     ` Junio C Hamano
2025-05-20  1:31                       ` JAYATHEERTH K
2025-05-20 15:28                         ` Junio C Hamano
2025-05-24  6:48                           ` [PATCH v6 0/2] Avoid submodule overwritten and skip redundant active entries K Jayatheerth
2025-05-24  6:48                             ` [PATCH v6 1/2] submodule: prevent overwriting .gitmodules entry on path reuse K Jayatheerth
2025-05-24  6:48                             ` [PATCH v6 2/2] submodule: skip redundant active entries when pattern covers path K Jayatheerth
2025-05-24  6:54                               ` JAYATHEERTH K
2025-05-24  7:30                                 ` [PATCH v7 0/2] Avoid submodule overwritten and skip redundant active entries K Jayatheerth
2025-05-24  7:30                                   ` [PATCH v7 1/2] The seventeenth batch K Jayatheerth
2025-05-24  7:33                                     ` JAYATHEERTH K
2025-05-24  7:30                                   ` [PATCH v7 2/2] submodule: prevent overwriting .gitmodules entry on path reuse K Jayatheerth

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=xmqqplga6c80.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jayatheerthkulkarni2005@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 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 NNTP newsgroup(s).