All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: Per Cederqvist <ceder@lysator.liu.se>, git@vger.kernel.org
Subject: Re: [PATCH] remote: detect collisions in remote names
Date: Mon, 7 Jul 2025 11:14:05 +0200	[thread overview]
Message-ID: <aGuP3Q5xykmRNp0m@pks.im> (raw)
In-Reply-To: <20250705185842.GA2496172@coredump.intra.peff.net>

On Sat, Jul 05, 2025 at 02:58:42PM -0400, Jeff King wrote:
> On Sat, Jul 05, 2025 at 12:57:50PM -0400, Jeff King wrote:
> 
> > So I dunno. It feels like a configuration error in most cases, but not
> > all. I'd probably say that people touching the config manually should be
> > allowed to do what they want, but maybe "git remote" should be a bit
> > more careful about names being proper subsets of existing remotes (it
> > should already prevent the exact-match above, I'd think, because the ref
> > namespace it uses will always match the configuration name).
> 
> So I'm not entirely convinced we should do anything here. The answer
> might just be "if it hurts, don't do it". But if we wanted any
> protections in the "git remote" porcelain, they might look like this:

I think having these protections is sensible. And I also agree with you
that we shouldn't keep people from doing weird things by manipulating
the config directly.

> diff --git a/builtin/remote.c b/builtin/remote.c
> index 0d6755bcb7..b18730ddb2 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -157,6 +157,21 @@ static int parse_mirror_opt(const struct option *opt, const char *arg, int not)
>  	return 0;
>  }
>  
> +static int check_remote_collision(struct remote *remote, void *vname)

Tiniest nit: I was a bit puzzled what the `v` in `vname` stands for, and
it took a while until I noticed that it probably stands for `void`. If
you end up rerolling, I'd suggest to either call this `payload` or
`_name`.

> +{
> +	const char *name = vname;
> +	const char *p;
> +
> +	if (skip_prefix(name, remote->name, &p) && *p == '/')
> +		die(_("remote name '%s' is a subset of existing remote '%s'"),
> +		    name, remote->name);
> +	if (skip_prefix(remote->name, name, &p) && *p == '/')
> +		die(_("remote name '%s' is a superset of existing remote '%s'"),
> +		    name, remote->name);
> +
> +	return 0;
> +}
> +

Hm. Do we have to care about '\' on Windows, as well? This made me
rediscover the following function:

    static int valid_remote_nick(const char *name)
    {
    	if (!name[0] || is_dot_or_dotdot(name))
    		return 0;
    
    	/* remote nicknames cannot contain slashes */
    	while (*name)
    		if (is_dir_sep(*name++))
    			return 0;
    	return 1;
    }

Which... puzzled me a bit at first, as it seems to indicate that a
remote with a path separator is invalid. But as it turns out we only use
this function if remotes are configured via ".git/remotes" or
".git/branches". Looks like we eventually lost this limitation, probably
when config-based remotes were introduced.

> @@ -208,6 +223,8 @@ static int add(int argc, const char **argv, const char *prefix,
>  	if (!valid_remote_name(name))
>  		die(_("'%s' is not a valid remote name"), name);
>  
> +	for_each_remote(check_remote_collision, (void *)name);
> +
>  	strbuf_addf(&buf, "remote.%s.url", name);
>  	git_config_set(buf.buf, url);
>  

Nice and simple.

Patrick

  reply	other threads:[~2025-07-07  9:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 19:33 Allowing "/" in the name of a git remote is a strange choice Per Cederqvist
2025-07-04  4:51 ` Junio C Hamano
2025-07-04  5:13   ` Patrick Steinhardt
2025-07-04  8:10     ` Lidong Yan
2025-07-04  8:17     ` Lidong Yan
2025-07-04 14:18     ` Junio C Hamano
2025-07-04  6:42   ` Per Cederqvist
2025-07-05 16:57 ` Jeff King
2025-07-05 18:58   ` [PATCH] remote: detect collisions in remote names Jeff King
2025-07-07  9:14     ` Patrick Steinhardt [this message]
2025-07-07 20:28       ` Jeff King
2025-07-07 21:04         ` Junio C Hamano
2025-07-08 22:59           ` Jeff King
2025-07-08 23:02             ` Jeff King
2025-07-08 23:28             ` Junio C Hamano
2025-07-09  1:21               ` Jeff King
2025-07-07 13:59     ` Junio C Hamano
2025-07-09 11:56     ` Raymond E. Pasco

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=aGuP3Q5xykmRNp0m@pks.im \
    --to=ps@pks.im \
    --cc=ceder@lysator.liu.se \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.