git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Barag <sean@barag.org>
To: gitster@pobox.com
Cc: git@vger.kernel.org, gitgitgadget@gmail.com,
	johannes.schindelin@gmx.de, sean@barag.org
Subject: Re: [PATCH 3/4] clone: validate --origin option before use
Date: Wed, 16 Sep 2020 10:11:51 -0700	[thread overview]
Message-ID: <20200916171151.1890682-1-sean@barag.org> (raw)
In-Reply-To: <xmqq1rj8nj47.fsf@gitster.c.googlers.com>

On Fri, 11 Sep 2020 at 13:39:20 -0700, Junio C Hamano writes:
> > From: Sean Barag <sean@barag.org>
> >
> > Providing a bad origin name to `git clone` currently reports an
> > 'invalid refspec' error instead of a more explicit message
> > explaining that the `--origin` option was malformed.  Per Junio,
> > it's been this way since 8434c2f1 (Build in clone, 2008-04-27).
>
> If you know it as a fact that it has been this way since the first
> version of rewritten "git clone", don't blame others.

Oh gosh, I'm so sorry!  I didn't mean for that to read as blaming, was
just trying to cite you as my source.  On a second read, it comes across
more "blame-y" than I originally intended.  I'll fix this in v2 (and
have learned a valuable lesson :) ).

> A micronit.  We describe the current status in present tense when
> presenting the problem to be solved, so "currently" can be dropped.
>
> > This patch reintroduces
>
> When presenting the solution, we write as if we are giving an order
> to a patch monkey to "make the code like so".
>
> "This patch reintroduces" -> "Reintroduce".

Great to know!  Thanks again for helping a newbie fit in.  Will fix in
v2.

> > validation for the provided `--origin` option, but notably _doesn't_
> > include a multi-level check (e.g. "foo/bar") that was present in the
> > original `git-clone.sh`.  It seems `git remote` allows multi-level
> > remote names, so applying that same validation in `git clone` seems
> > reasonable.
>
> Even though I suspect "git remote" is being overly loose and
> careless here, I am not sure if it is a good idea to tighten it
> retroactively.  But if this is meant as a bugfix for misconversion
> made in 8434c2f1, we should be as strict as the original.  I dunno.


To be honest, I'm struggling to decide which route to go.  It seems
like multilevel fetch and push refspecs are allowed as far back as
46220ca100 (remote.c: Fix overtight refspec validation, 2008-03-20) or
ef00d150e4 (Tighten refspec processing, 2008-03-17), so perhaps
removing the multilevel check in 8434c2f1 (Build in clone, 2008-04-27)
was intentional?  If removing that check in 8434c2f1 was a mistake and
we reintroduce it, that's probably a breaking change for some users.
What sort of accommodations would I need to include in this patchset to
ease that pain for users?

> > +	strbuf_addf(&resolved_refspec, "refs/heads/test:refs/remotes/%s/test", option_origin);
> > +	if (!valid_fetch_refspec(resolved_refspec.buf))
>
> If we reintroduce pre-8434c2f1 check, then we would want
>
> 	if (!valid_fetch_refspec(...) || strchr(option_origin, '/'))
>
> or something like that?

Absolutely!  Happy to include the multilevel check if you think it's the
right path forward (see above).

> > +		/* TRANSLATORS: %s will be the user-provided --origin / -o option */
> > +		die(_("'%s' is not a valid origin name"), option_origin);
>
> I am not sure if this translator comment is helping.
>
> The message makes it sound as if "%s" here is used to switch between
> '-o' or '--origin'.  If it said "'%s' will be the value given to
> --origin/-o option", it would become much less confusing.

Agreed.  I plan to take Derrick's suggestion [1] and use the same
" is not a valid remote name" message from `builtin/remote.c`, which
should make that translator comment a non-issue.

[1] https://lore.kernel.org/git/bf0107fb-2a6c-68d3-df24-72c6a9df6182@gmail.com/


I can't stress enough how sorry I am for the improper blame, and how
much I appreciate your help!
--
Sean

  reply	other threads:[~2020-09-16 20:35 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 18:25 [PATCH 0/4] clone: allow configurable default for -o/--origin Sean Barag via GitGitGadget
2020-09-11 18:25 ` [PATCH 1/4] clone: add tests for --template and some disallowed option pairs Sean Barag via GitGitGadget
2020-09-11 18:57   ` Derrick Stolee
2020-09-11 19:56     ` Jeff King
2020-09-11 20:07       ` Eric Sunshine
2020-09-16  3:15         ` [PATCH 0/4] clone: allow configurable default for -o/--origin Sean Barag
2020-09-12  3:17       ` [PATCH 1/4] clone: add tests for --template and some disallowed option pairs Taylor Blau
2020-09-15 16:09       ` Sean Barag
2020-09-16 16:36         ` Jeff King
2020-09-11 21:02     ` Junio C Hamano
2020-09-12  0:41       ` Derrick Stolee
2020-09-11 18:25 ` [PATCH 2/4] clone: call git_config before parse_options Sean Barag via GitGitGadget
2020-09-11 18:59   ` Derrick Stolee
2020-09-11 20:26   ` Junio C Hamano
2020-09-16 16:12     ` Sean Barag
2020-09-11 18:25 ` [PATCH 3/4] clone: validate --origin option before use Sean Barag via GitGitGadget
2020-09-11 19:24   ` Derrick Stolee
2020-09-16 16:28     ` Sean Barag
2020-09-11 20:39   ` Junio C Hamano
2020-09-16 17:11     ` Sean Barag [this message]
2020-09-21 16:13       ` Sean Barag
2020-09-11 18:25 ` [PATCH 4/4] clone: allow configurable default for `-o`/`--origin` Sean Barag via GitGitGadget
2020-09-11 19:13   ` Derrick Stolee
2020-09-28 16:04     ` Sean Barag
2020-09-11 21:00   ` Junio C Hamano
2020-09-28 16:02     ` Sean Barag
2020-09-17 15:25   ` Andrei Rybak
2020-09-11 19:25 ` [PATCH 0/4] clone: allow configurable default for -o/--origin Derrick Stolee
2020-09-11 19:34 ` Junio C Hamano
2020-09-29  3:36 ` [PATCH v2 0/7] " Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 1/7] clone: add tests for --template and some disallowed option pairs Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 2/7] clone: use more conventional config/option layering Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 3/7] remote: add tests for add and rename with invalid names Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 4/7] refs: consolidate remote name validation Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 5/7] clone: validate --origin option before use Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 6/7] clone: read new remote name from remote_name instead of option_origin Sean Barag via GitGitGadget
2020-09-29  3:36   ` [PATCH v2 7/7] clone: allow configurable default for `-o`/`--origin` Sean Barag via GitGitGadget
2020-09-29 19:59     ` Junio C Hamano
2020-09-29 23:47       ` [PATCH] clone: add remote.cloneDefault config option Sean Barag
2020-09-29  3:44   ` [PATCH v2 0/7] clone: allow configurable default for -o/--origin Sean Barag
2020-10-01  3:46   ` [PATCH v3 " Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 1/7] clone: add tests for --template and some disallowed option pairs Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 2/7] clone: use more conventional config/option layering Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 3/7] remote: add tests for add and rename with invalid names Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 4/7] refs: consolidate remote name validation Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 5/7] clone: validate --origin option before use Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 6/7] clone: read new remote name from remote_name instead of option_origin Sean Barag via GitGitGadget
2020-10-01  3:46     ` [PATCH v3 7/7] clone: allow configurable default for `-o`/`--origin` Sean Barag via GitGitGadget
2020-10-02 12:56     ` [PATCH v3 0/7] clone: allow configurable default for -o/--origin Derrick Stolee

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=20200916171151.1890682-1-sean@barag.org \
    --to=sean@barag.org \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    /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).