git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Christian Couder <chriscool@tuxfamily.org>,
	Daniel Barkalow <barkalow@iabervon.org>
Subject: Re: [PATCH 07/14] revert: Introduce struct to keep command-line options
Date: Wed, 6 Jul 2011 16:50:14 +0530	[thread overview]
Message-ID: <CALkWK0=gm-y3CB83TsSiWWF4qyS5hOJDhOYCz4HTWyT7iHP6MA@mail.gmail.com> (raw)
In-Reply-To: <20110706090915.GD15682@elie>

Hi,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>> In later
>> steps in this series, we would like to introduce an API function that
>> calls into this machinery directly and have a way to tell it what to
>> do.  Hence, introduce a structure to group these variables, so that
>> the API can take them as a single replay_options parameter.
>>
>> The variable "me" is left as a file-scope static variable because it
>> is not an independent option.  "me" is simply a string that needs to
>> be inferred from the "action" option, and is kept global to save each
>> function the trouble of determining it independently.
>
> Hm, would it make sense for there to be a "private" section at the
> end of the replay_opts struct for variables like this?

No.  My justification: in later steps, we'd want to be able to mix
"pick" and "revert" instructions in the same instruction sheet.  This
will essentially require the parser to return a commit + a replay_opts
struct (which will contain the action information).  There's little
point in storing 100 "revert" strings for the 100 commits we want to
pick when that can easily be inferred from the action.

>> Unfortunately, this patch introduces a minor regression.  Parsing
>> strategy-option violates a C89 rule: Initializers cannot refer to
>> variables whose address is not known at compile time.  Currently, this
>> rule is violated by some other parts of Git as well, and it is
>> possible to get GCC to report these instances using the "-std=c89
>> -pedantic" option.
>
> I would be interested in fixing that (as a patch on top, maybe).
> What do you suggest:
>
>  A. Apply patch 8 and make cmd_revert, cmd_cherry_pick, and parse_args
>    manipulate a static "struct replay_opts" while pick_commits et al
>    pass around a pointer to it
>
>  B. Make parse_args work like this:
>
>        copy from argument to private static struct replay_opts
>        call parse_options()
>        copy private static struct replay_opts to argument

This is something you suggested earlier, but I find it extremely inelegant.

>  C. Use new option types:
>
>        OPT_BOOL_MEMBER('n', "no-commit",
>                offsetof(struct replay_opts, no_commit),
>                "don't automatically commit"),
>
>    and teach parse_options to take an additional parameter like it
>    takes "prefix" now, to be used as a base address for options that
>    write to an offset instead of a pointer
>
> I'm leaning towards A but not sure if that would be wasted work in
> light of your plans for these APIs in the long run (i.e., is
> parse_args() going to be exposed and want to act on a caller-supplied
> struct)?

Yes, I'm definitely considering exposing parse_args in the future,
especially since I want to support command-line options in my
instruction sheet.  Implementing (C) correctly will probably have
several long-term benefits as well -- what do you feel about it?

-- Ram

  reply	other threads:[~2011-07-06 11:20 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06  7:54 [GSoC update] Sequencer: The insn sheet format Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 01/14] advice: Introduce error_resolve_conflict Ramkumar Ramachandra
2011-07-06  8:35   ` Jonathan Nieder
2011-07-06  9:28     ` Ramkumar Ramachandra
2011-07-06 10:03       ` Jonathan Nieder
2011-07-06  7:54 ` [PATCH 02/14] revert: Inline add_message_to_msg function Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 03/14] revert: Don't check lone argument in get_encoding Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 04/14] revert: Rename no_replay to record_origin Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 05/14] revert: Propogate errors upwards from do_pick_commit Ramkumar Ramachandra
2011-07-06  8:50   ` Jonathan Nieder
2011-07-06  9:30     ` Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 06/14] revert: Eliminate global "commit" variable Ramkumar Ramachandra
2011-07-06  8:55   ` Jonathan Nieder
2011-07-06  9:37     ` Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 07/14] revert: Introduce struct to keep command-line options Ramkumar Ramachandra
2011-07-06  9:09   ` Jonathan Nieder
2011-07-06 11:20     ` Ramkumar Ramachandra [this message]
2011-07-06 12:06       ` Jonathan Nieder
2011-07-12  6:14         ` Ramkumar Ramachandra
2011-07-06 21:20   ` Junio C Hamano
2011-07-12  6:21     ` Ramkumar Ramachandra
2011-07-12  6:33       ` Jonathan Nieder
2011-07-06  7:54 ` [PATCH 08/14] revert: Separate cmdline parsing from functional code Ramkumar Ramachandra
2011-07-06  9:13   ` Jonathan Nieder
2011-07-06  9:34     ` Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 09/14] revert: Don't create invalid replay_opts in parse_args Ramkumar Ramachandra
2011-07-06  9:20   ` Jonathan Nieder
2011-07-06  7:54 ` [PATCH 10/14] revert: Persist data for continuation Ramkumar Ramachandra
2011-07-06 10:01   ` Jonathan Nieder
2011-07-06 11:55     ` Ramkumar Ramachandra
2011-07-06 21:20     ` Junio C Hamano
2011-07-06  7:54 ` [PATCH 11/14] revert: Introduce a layer of indirection over pick_commits Ramkumar Ramachandra
2011-07-06 10:37   ` Jonathan Nieder
2011-07-06 11:24     ` Ramkumar Ramachandra
2011-07-06 11:39       ` Jonathan Nieder
2011-07-06 11:44         ` Ramkumar Ramachandra
2011-07-06 11:53           ` Jonathan Nieder
2011-07-06 21:00   ` Junio C Hamano
2011-07-07  6:31     ` Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 12/14] revert: Introduce --reset to cleanup sequencer data Ramkumar Ramachandra
2011-07-06 10:14   ` Jonathan Nieder
2011-07-06 10:55     ` Ramkumar Ramachandra
2011-07-06 14:32   ` Ramkumar Ramachandra
2011-07-06 19:21     ` Jonathan Nieder
2011-07-06 19:56       ` Jonathan Nieder
2011-07-07  3:03       ` Ramkumar Ramachandra
2011-07-06  7:54 ` [PATCH 13/14] revert: Introduce --continue to continue the operation Ramkumar Ramachandra
2011-07-06 10:25   ` Jonathan Nieder
2011-07-06 21:21   ` Junio C Hamano
2011-07-06 21:52     ` Drew Northup
2011-07-07  6:35     ` Ramkumar Ramachandra
2011-07-06  7:54 ` [RFC PATCH 14/14] revert: Change insn sheet format Ramkumar Ramachandra
2011-07-06 10:33   ` Jonathan Nieder
2011-07-06 10:49     ` Ramkumar Ramachandra
2011-07-06 10:41 ` [GSoC update] Sequencer: The " Jonathan Nieder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALkWK0=gm-y3CB83TsSiWWF4qyS5hOJDhOYCz4HTWyT7iHP6MA@mail.gmail.com' \
    --to=artagnon@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).