From: Sverre Rabbelier <srabbelier@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
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 21:40:00 +0200 [thread overview]
Message-ID: <fabb9a1e0909121240q67dbcd11ube72dcbbd276168e@mail.gmail.com> (raw)
In-Reply-To: <20090912190416.GS1033@spearce.org>
Heya,
On Sat, Sep 12, 2009 at 21:04, Shawn O. Pearce <spearce@spearce.org> wrote:
> The more I think about this, I may have to agree with Ian, I'm not
> sure option makes much sense.
Perhaps instead we can replace the option series with a few extra
features? That is 'feature git-quiet' (or maybe just 'feature quiet')
and 'feature git-marks' (or just 'feature marks', since its' fairly
generic)?
> 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.
This was why originally we aborted when we see an unrecognized option,
I agree that due to how the series has evolved this is not such a good
idea anymore.
> @@ -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.
Nope, parse_argv isn't called until after we encounter a non-git
option. I think there's a test that makes sure this works too.
> I thought on fast-import list we agreed that the syntax of option was:
Right.
> 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?
I wanted to make it obvious that we ignore non-git options; depending
on whether we want to keep the option part of this series in the first
place I'll either handle it all in parse_option or drop those patches.
--
Cheers,
Sverre Rabbelier
next prev parent reply other threads:[~2009-09-12 19:40 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 ` [PATCH v7 5/6] fast-import: add " Shawn O. Pearce
2009-09-12 19:40 ` Sverre Rabbelier [this message]
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=fabb9a1e0909121240q67dbcd11ube72dcbbd276168e@mail.gmail.com \
--to=srabbelier@gmail.com \
--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=spearce@spearce.org \
--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).