Re: [PATCH 7/7] fast-import: use struct option for usage string

On Thu, Jul 16, 2026 at 11:35=E2=80=AFPM Junio C Hamano <[email protected]>=
 wrote:

> OK, I am a bit torn on this.  On one hand:
>
>  (1) I do agree that it would be nice to eventually have
>      fast_import_state_init() (or some other helper that groks
>      argc/argv) use this options array to parse the command line
>      arguments.
>
>  (2) I am sympathetic to the position that doing so is a bit
>      outside the scope of this series, whose focus is strictly on
>      "git fast-import -h" and nothing else.
>
>  (3) I suspect that when fast_import_state_init() does start using
>      the options array to initialize the state, the parsed results
>      will not be stored in the variables this caller currently holds,
>      but will instead live inside the fast_import_state structure.
>
> So in that sense, the huge list of unused function-local variables
> above are merely throw-away placeholders.  When the real code is
> written, they will disappear, and the references to them in the
> fast_import_options[] array will have to be updated to point to
> members of the structure (or global variables).
>
> Still, seeing all of those variables left uninitialized leaves a
> slightly sour taste.  And because of (3), it would be a clear waste
> of time to go through the motions of initializing these throw-away
> locals.
>
> Perhaps we would end up in a better position if we bent (2) a bit.
> After all, my hesitation likely stems from the feeling that this
> series stops short at a slightly awkward spot, having already
> completed 90% of the journey.
>
> For example, instead of inventing a local, throw-away
> "pack_size_limit" variable, wouldn't it make more sense to refer to
> the existing global "max_packsize" variable from the options[]
> array below?

Yeah, this can work for some variables. But anyway I have tried to
fully move to using the parse-option API to actually parse the command
line options, and I hope to send the result in a v2 soon.