git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Git List <git@vger.kernel.org>,
	Ian Clatworthy <ian.clatworthy@canonical.com>,
	Matt McClure <mlm@aya.yale.edu>,
	Miklos Vajna <vmiklos@frugalware.org>,
	Julian Phillips <julian@quantumfyre.co.uk>,
	vcs-fast-import-devs@lists.launchpad.net
Subject: Re: [PATCH v7 5/6] fast-import: add option command
Date: Sat, 12 Sep 2009 12:04:16 -0700	[thread overview]
Message-ID: <20090912190416.GS1033@spearce.org> (raw)
In-Reply-To: <1252247748-14507-6-git-send-email-srabbelier@gmail.com>

Sverre Rabbelier <srabbelier@gmail.com> wrote:
> This allows the frontend to specify any of the supported options as
> long as no non-option command has been given. This way the
> user does not have to include any frontend-specific options, but
> instead she can rely on the frontend to tell fast-import what it
> needs.
...
> @@ -2456,11 +2468,32 @@ static void parse_feature(void)
>  
>  	if (!prefixcmp(feature, "date-format=")) {
>  		option_date_format(feature + 12);
> +	} else if (!strcmp("git-options", feature)) {
> +		options_enabled = 1;

No.  We do not want to require "feature git-options" in order to
use "option git foo", because "feature git-options" will cause an
Hg importer to abort on the same stream.

Options are meant to be optional.  If the importer recognizes the
line, it should use it.  But if it does not, it should continue
anyway.

The more I think about this, I may have to agree with Ian, I'm not
sure option makes much sense.

You started this series so you could embed Git specific command line
options in the stream, rather than on the command line for git-hg.

But what should happen if "option import-marks=bleh" isn't
understood by fast-import?  Wouldn't the stream be useless anyway,
because the marks it assumes aren't present?  Or worse, "option
export-marks=bleh" isn't recognized.  The stream imports, but any
marks it was supposed to store for the frontend to reuse later
are gone.

> +static void parse_nongit_option(void)
> +{
> +	/* do nothing */
> +}

Please don't do this.  What a waste of code.

> @@ -2485,6 +2518,27 @@ static int git_pack_config(const char *k, const char *v, void *cb)
>  static const char fast_import_usage[] =
>  "git fast-import [--date-format=f] [--max-pack-size=n] [--depth=n] [--active-branches=n] [--export-marks=marks.file]";
>  
> +static void parse_argv(void)
> +{
> +	unsigned int i;
> +
> +	for (i = 1; i < global_argc; i++) {
> +		const char *a = global_argv[i];
> +
> +		if (*a != '-' || !strcmp(a, "--"))
> +			break;
> +
> +		/* error on unknown options */
> +		parse_one_option(a + 2, 0);
> +	}
> +	if (i != global_argc)
> +		usage(fast_import_usage);
> +
> +	seen_non_option_command = 1;

So if I pass a single command line option, like --export-marks,
we die if we see an "option git " inside of the stream?  That's not
what we wanted to do.

> @@ -2539,9 +2583,18 @@ int main(int argc, const char **argv)
>  			parse_progress();
>  		else if (!prefixcmp(command_buf.buf, "feature "))
>  			parse_feature();
> +		else if (!prefixcmp(command_buf.buf, "option git "))
> +			parse_option();
> +		else if (!prefixcmp(command_buf.buf, "option "))
> +			parse_nongit_option();

I thought on fast-import list we agreed that the syntax of option was:

  'option' SP vcs SP option

  vcs ::= 'git' | 'hg' | 'bzr' | ...
  option ::= name ('=' value)?
  name = ^[a-zA-Z][a-zA-Z-]*$
  value = quoted_string

So what is this parse_nongit_option() for, other than to obfuscate
the code?  Can't we handle all of this in parse_option, have it
check the VCS tag, and return early there?

-- 
Shawn.

  parent reply	other threads:[~2009-09-12 19:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-06 14:35 [PATCH v7 0/6] fast-import: add new feature and option command Sverre Rabbelier
2009-09-06 14:35 ` [PATCH v7 1/6] fast-import: put option parsing code in separate functions Sverre Rabbelier
2009-09-06 14:35   ` [PATCH v7 2/6] fast-import: put marks reading in it's own function Sverre Rabbelier
2009-09-06 14:35     ` [PATCH v7 3/6] fast-import: add feature command Sverre Rabbelier
2009-09-06 14:35       ` [PATCH v7 4/6] fast-import: test the new " Sverre Rabbelier
2009-09-06 14:35         ` [PATCH v7 5/6] fast-import: add option command Sverre Rabbelier
2009-09-06 14:35           ` [PATCH v7 6/6] fast-import: test the new " Sverre Rabbelier
2009-09-12 19:04           ` Shawn O. Pearce [this message]
2009-09-12 19:40             ` [PATCH v7 5/6] fast-import: add " Sverre Rabbelier
2009-09-12 18:52         ` [PATCH v7 4/6] fast-import: test the new feature command Shawn O. Pearce
2009-09-12 19:31           ` Sverre Rabbelier
2009-09-13 13:20             ` Miklos Vajna
2009-09-12 18:51       ` [PATCH v7 3/6] fast-import: add " Shawn O. Pearce
2009-09-12 19:43         ` Sverre Rabbelier
2009-09-12 18:47     ` [PATCH v7 2/6] fast-import: put marks reading in it's own function Shawn O. Pearce

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=20090912190416.GS1033@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ian.clatworthy@canonical.com \
    --cc=julian@quantumfyre.co.uk \
    --cc=mlm@aya.yale.edu \
    --cc=srabbelier@gmail.com \
    --cc=vcs-fast-import-devs@lists.launchpad.net \
    --cc=vmiklos@frugalware.org \
    /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).