All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 3/8] revert: Introduce a struct to parse command-line options into
Date: Fri, 13 May 2011 15:02:56 +0530	[thread overview]
Message-ID: <20110513093253.GD14272@ramkum.desktop.amazon.com> (raw)
In-Reply-To: <20110511112438.GD2676@elie>

Hi again,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
> 
> >  I get the following warning from GCC: warning: useless storage class
> >  specifier in empty declaration (at the line where I've declared the
> >  replay_opts struct).  What is the correct way to fix this?
> 
> Remove the useless storage class specifier ("static"). :)

Ah, thanks :)

> > --- a/builtin/revert.c
> > +++ b/builtin/revert.c
> > @@ -35,29 +35,42 @@ static const char * const cherry_pick_usage[] = {
> [...]
> > +static struct replay_opts {
> > +	enum { REVERT, CHERRY_PICK } action;
> > +
> > +	/* Boolean options */
> > +	int edit;
> > +	int no_replay;
> 
> replay but no replay?
> 
> I think originally git-revert.sh had a "replay" variable meaning "This
> is not a revert (which undoes a commit) but a cherry-pick (which
> re-does it)."  Later the purpose changed to "We are not cherry-picking
> and referring to the original with cherry-pick -x but replaying a
> commit and treating it as new".
> 
> Now with struct replay_opts you are proposing to make the term mean
> "we are using git revert machinery, or in other words replaying the
> change an old commit made (forwards or backwards)", which makes sense.
> In this case there should probably be a patch right before which
> renames no_replay to i_really_want_to_expose_my_private_commit_object_name
> (um, I mean to record_origin or something similar).

Great suggestion: one more patch changing "no_replay" to
"record_origin" it is.

> > +	int no_commit;
> > +	int signoff;
> > +	int allow_ff;
> > +	int allow_rerere_auto;
> > +
> > +	int mainline;
> > +	int commit_argc;
> > +	const char **commit_argv;
> > +
> > +	/* Merge strategy */
> > +	const char *strategy;
> > +	const char **xopts;
> > +	size_t xopts_nr, xopts_alloc;
> > +};
> [...]
> >  
> > -static const char * const *revert_or_cherry_pick_usage(void)
> > +static const char *const *revert_or_cherry_pick_usage(struct replay_opts *opts)
> 
> Line is getting long.  Whitespace change snuck in?

In my defense, I thought whitespace (indentation, style) changes were
permitted as long as I'm making a functional change.  If this isn't
the case, when can I correct the style/ indentation?

> I suppose if I ran the world the argument would be of type "enum
> replay_action", so it would be used as
> 
> 	usage(revert_or_cherry_pick_usage(o->action));
> 
> > +/* For option_parse_x */
> > +static const char **xopts;
> > +static size_t xopts_nr, xopts_alloc;
> > +
> 
> Hm.  In C89, struct initializers are not allowed to include addresses
> that are not known until run-time, and we used to follow that and now
> violate it all over the place.  I'm not sure if it's worth it or not.
> (I'm tempted to say, let it deteriorate further and people with the
> ability to test on such platforms can fix it, but commits like
> v1.7.2-rc0~32^2~18, Rewrite dynamic structure initializations to
> runtime assignment, 2010-05-14, suggest that some people have cared in
> the recent future.)
> 
> So.
> 
> If you want to use parse_options and support such compilers, it is
> indeed simplest to use static variables.  You can give them scope
> local to a particular function to at least avoid namespace polution.
> 
> To avoid such static variables at the expense of support for old
> compilers, one can pass a pointer to a struct to option_parse_x
> instead of the dummy &xopts.  Within option_parse_x, what you pass
> will be accessible as opt->value.  It's all explained in
> Documentation/technical/api-parse-options.txt, or one can grep around
> for OPT_CALLBACK for examples.  A simple variant on this will work
> with the old compilers, too.

Got it.

> [...]
> >  static int option_parse_x(const struct option *opt,
> > -			  const char *arg, int unset)
> > +			const char *arg, int unset)
> 
> Whitespace change snuck in.

Intended.  It changes indentation style to linux-tabs-only, which is
the style my editor currently works with.

> [...]
> > @@ -67,19 +80,18 @@ static int option_parse_x(const struct option *opt,
> >  	return 0;
> >  }
> >  
> > -static void parse_args(int argc, const char **argv)
> > +static void parse_args(int argc, const char **argv, struct replay_opts *opts)
> >  {
> > -	const char * const * usage_str = revert_or_cherry_pick_usage();
> > +	const char *const *usage_str = revert_or_cherry_pick_usage(opts);
> >  	int noop;
> >  	struct option options[] = {
> > -		OPT_BOOLEAN('n', "no-commit", &no_commit, "don't automatically commit"),
> > +		OPT_BOOLEAN('n', "no-commit", &(opts->no_commit), "don't automatically commit"),
> 
> The parentheses are not needed (and not idiomatic fwiw).  The line is
> getting long so I'd suggest splitting it, though that's more a matter
> of taste.

Ok, I'll lose the paranthesis.

> > @@ -87,23 +99,29 @@ static void parse_args(int argc, const char **argv)
> [...]
> > -	if (commit_argc < 2)
> > +
> > +	/* Fill in the opts struct from values set by option_parse_x */
> > +	opts->xopts = xopts;
> > +	opts->xopts_nr = xopts_nr;
> > +	opts->xopts_alloc = xopts_alloc;
> 
> Yep, something like this is needed (for all the options) if we want to
> follow C89's option-struct-initialization rules.

Ouch! That's much too painful :|
I think I'll break the rule for the moment.

> >  static int do_recursive_merge(struct commit *base, struct commit *next,
> > -			      const char *base_label, const char *next_label,
> > -			      unsigned char *head, struct strbuf *msgbuf)
> > +			const char *base_label, const char *next_label,
> > +			unsigned char *head, struct strbuf *msgbuf,
> > +			struct replay_opts *opts)
> 
> I'm not going to point out whitespace changes that snuck in any more.
> 
> I think I prefer the options struct to go in front (as in the
> merge-recursive and diff APIs), but this is only a matter of taste.

Intended again, since I'm adding an argument to the list.

> > @@ -311,15 +329,15 @@ static int fast_forward_to(const unsigned char *to, const unsigned char *from)
> >  }
> >  
> >  {
> >  	struct merge_options o;
> >  	struct tree *result, *next_tree, *base_tree, *head_tree;
> >  	int clean, index_fd;
> >  	const char **xopt;
> >  	static struct lock_file index_lock;
> > -	const char *me = (action == REVERT ? "revert" : "cherry-pick");
> 
> I think this belongs in a different patch (and likewise for its
> counterpart below).
> 
> > The current code uses a set of file-scope static variables to tell the
> > cherry-pick/ revert machinery how to replay the changes, and
> > initializes them by parsing the command-line arguments.  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.
> 
> Stepping back, I think this is a good idea, to make the state being
> passed around a little clearer and to make it easier for callers to
> specify what they want to happen without making up fictitious argc and
> argv.  Most of what remains for this to be cooked are minor things
> (the biggest part is getting it to build with -std=c89 -pedantic if
> wanted and teaching option_parse_x to use a callback parameter).

Right, thanks.

-- Ram

  reply	other threads:[~2011-05-13  9:33 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11  8:00 [PATCH 0/8] Sequencer Foundations Ramkumar Ramachandra
2011-05-11  8:00 ` [PATCH 1/8] revert: Improve error handling by cascading errors upwards Ramkumar Ramachandra
2011-05-11  9:59   ` Jonathan Nieder
2011-05-13 10:30     ` Ramkumar Ramachandra
2011-05-19 10:39     ` Ramkumar Ramachandra
     [not found]     ` <20110519091831.GA28723@ramkum.desktop.amazon.com>
2011-05-19 18:03       ` Jonathan Nieder
2011-05-20  6:39         ` Ramkumar Ramachandra
2011-05-11  8:00 ` [PATCH 2/8] revert: Make "commit" and "me" local variables Ramkumar Ramachandra
2011-05-11 10:37   ` Jonathan Nieder
2011-05-13 10:02     ` Ramkumar Ramachandra
2011-05-13 21:40   ` Daniel Barkalow
2011-05-11  8:00 ` [PATCH 3/8] revert: Introduce a struct to parse command-line options into Ramkumar Ramachandra
2011-05-11 11:24   ` Jonathan Nieder
2011-05-13  9:32     ` Ramkumar Ramachandra [this message]
2011-05-13 10:07       ` Jonathan Nieder
2011-05-13 10:22         ` Ramkumar Ramachandra
2011-05-11  8:00 ` [PATCH 4/8] revert: Separate cmdline argument handling from the functional code Ramkumar Ramachandra
2011-05-11 11:49   ` Jonathan Nieder
2011-05-13  9:09     ` Ramkumar Ramachandra
2011-05-13  9:35       ` Ramkumar Ramachandra
2011-05-13  9:44         ` Jonathan Nieder
2011-05-11  8:00 ` [PATCH 5/8] revert: Catch incompatible command-line options early Ramkumar Ramachandra
2011-05-11 12:06   ` Jonathan Nieder
2011-05-13 10:07     ` Ramkumar Ramachandra
2011-05-11  8:00 ` [PATCH 6/8] revert: Introduce head, todo, done files to persist state Ramkumar Ramachandra
2011-05-11 12:47   ` Jonathan Nieder
2011-05-13 10:21     ` Ramkumar Ramachandra
2011-05-11  8:00 ` [PATCH 7/8] revert: Implement parsing --continue, --abort and --skip Ramkumar Ramachandra
2011-05-11 12:59   ` Jonathan Nieder
2011-05-13  9:16     ` Ramkumar Ramachandra
2011-05-13  9:40       ` Jonathan Nieder
2011-05-11  8:00 ` [PATCH 8/8] revert: Implement --abort processing Ramkumar Ramachandra
2011-05-11 13:14 ` [PATCH 0/8] Sequencer Foundations Jonathan Nieder
2011-05-12  8:19   ` Christian Couder
2011-05-12  8:41     ` Jonathan Nieder
2011-05-12 11:44       ` Jonathan Nieder
2011-05-13  9:11         ` Christian Couder
2011-05-13 10:37           ` Jonathan Nieder
2011-05-16  4:14             ` Christian Couder

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=20110513093253.GD14272@ramkum.desktop.amazon.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.
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.