git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Pierre Habouzit <madcoder@debian.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH] Use parseopts in builtin-fetch
Date: Mon, 5 Nov 2007 12:41:04 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0711051215260.7357@iabervon.org> (raw)
In-Reply-To: <20071105085513.GB25574@artemis.corp>

On Mon, 5 Nov 2007, Pierre Habouzit wrote:

> On Mon, Nov 05, 2007 at 03:35:34AM +0000, Daniel Barkalow wrote:
> > I mostly did this and the next one for practice with the API. I'm 
> > impressed that "git fetch -vv" is even handled correctly without anything 
> > special.
> 
>   About that: OPTION_BOOLEAN increments the associated variable, to
> support this case specifically.
> 
>   The last thing that really miss in parse-options is a way to recurse
> into a sub-array of struct option, to be able to port the generic diff
> and revision arguments.
> 
>   Though, there is a difficulty here that I've not yet found how to
> circumvent tastefully: right now options take an absolute pointer to
> _the_ variable that will be filled with values. I need to be able to
> relocate such a structure for sub-arrays for quite obvious reasons, and
> that is quite hard to achieve without hazardous APIs. I currently lean
> in the direction of simply memdup-ing the array and do fix-ups on
> *values pointers. Though how to do that in a graceful way is not obvious
> to me yet :)

I'm not entirely clear as to why the "diff options" to an arbitrary 
command can't configure variables in the diff engine. The tricky thing 
would be supporting a single command that has two sets of the same 
options (if git log could show the same stuff in two different ways at the 
same time, for example).

But, in any case, it should be possible for an OPT_* macro to take a 
struct type and a member name, do the offsetof and store that, and the 
inclusion macro would take the absolute pointer to the struct.

Next time I get a chance, I'll see if I can come up with something 
suitable.

	-Daniel
*This .sig left intentionally blank*

  parent reply	other threads:[~2007-11-05 17:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05  3:35 [PATCH] Use parseopts in builtin-fetch Daniel Barkalow
2007-11-05  8:43 ` Pierre Habouzit
2007-11-05 17:14   ` Daniel Barkalow
2007-11-05  8:55 ` Pierre Habouzit
2007-11-05 17:02   ` Kristian Høgsberg
2007-11-05 17:41   ` Daniel Barkalow [this message]
2007-11-05 19:13   ` Junio C Hamano
2007-11-05 19:48     ` Pierre Habouzit

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=Pine.LNX.4.64.0711051215260.7357@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=madcoder@debian.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).