Re: [PATCH v2 1/3] builtin/commit-graph.c: support '--split[=<strategy>]'

From: Martin Ågren <martin.agren@gmail.com>
Date: Feb 12, 2020, 06:03 UTC
Message-ID: <CAN0heSrNJ5XdJ=w=xgNQORAyprOD6xudivveroXV-OJwO6nBvg@mail.gmail.com>
In-Reply-To: <3acac399-9476-e4ad-556e-e0138380eeb0@gmail.com>

On Fri, 7 Feb 2020 at 16:48, Derrick Stolee <stolee@gmail.com> wrote:

Show 27 quoted lines

>
> On 2/6/2020 2:41 PM, Martin Ågren wrote:
> > On Wed, 5 Feb 2020 at 01:28, Taylor Blau <me@ttaylorr.com> wrote:
> >> -               OPT_BOOL(0, "split", &opts.split,
> >> -                       N_("allow writing an incremental commit-graph file")),
> >> +               OPT_CALLBACK_F(0, "split", &split_opts.flags, NULL,
> >> +                       N_("allow writing an incremental commit-graph file"),
> >> +                       PARSE_OPT_OPTARG | PARSE_OPT_NONEG,
> >> +                       write_option_parse_split),
> >
> >
> > I keep getting back to this -- sorry! So this actually forbids
> > "--no-split", which used to work before. Unfortunate?
>
> That certainly is unfortunate. Hopefully no one is taking a dependence on
> this, which only means something if they had a `--split` previously in
> the command-line arguments.
>
> > I have to ask, what is the long-term plan for the two formats (split and
> > non-split)? As I understand it, and I might well be wrong, the non-split
> > format came first and the split format was a user-experience
> > improvement. Should we expect that `--split` becomes the default?
>
> In some ways, the split is now the default because that is how it is
> written during 'git fetch' using fetch.writeCommitGraph. However, I
> don't think that it will ever become the default for the commit-graph
> builtin.

Thanks for giving this piece of background.

Show 5 quoted lines

> > To try to be concrete, here's a suggestion: `--format=split` and
> > `--split-strategy=<strategy>`.
>
> Why --format=split instead of leaving it as --[no-]split? Is there a reason to
> introduce this string-based option when there are only two options right now?

My thinking was, if my concern is "--split" being overloaded, what would it look like to "unload" it entirely? From "--split" it isn't obvious whether it's a verb or an adjective (shall we split, or shall we do things the split way?). Having "--format=split" would help avoid *that*, possibly leaving a cleaner field for the issue of "do we allow/force/forbid the 'merging' to happen?". But I'm happy to accept "--split=<strategy>" and move on. :-)

I see that Taylor juuust posted a v3. I'll try to find time to look it over, but I won't be raising this point again.

Martin