Re: [PATCH] technical doc: add a design doc for the evolve command
- Date: Mon, 19 Nov 2018 17:09:11 -0800
- From: Jonathan Nieder <jrnieder@xxxxxxxxx>
- Subject: Re: [PATCH] technical doc: add a design doc for the evolve command
Stefan Xenos wrote:
> But since several comments have focused on the commands, let's brainstorm!
> Here's some options that occur to me:
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the change graph and metas/ namespace.
> 2. All top-level: evolve + lschange + mkchange + rmchange +
> prunechange + obslog. None of the commands get subcommands.
> 3. Everything under change: "change evolve", "change obslog" become
> new change subcommands.
> 4. Evolve as a rebase argument, obslog as a log argument. Use "rebase
> --evolve" to initiate evolve and use "log --obslog" to initiate
> obslog. The change command stays as it is in the proposal.
> 5. Two commands: evolve + change. obslog becomes a "log" argument.
> Note that there will be more "evolve"-specific arguments in the
> future. For most transformations that evolve uses, there will be a
> matching argument to enable or disable that transformation and as we
> add transformations we'll also add arguments.
> If we go with option 3, it would make for a very cluttered help page.
> For example, if you're looking for information on how to use evolve,
> you'd have to scroll past a bunch of formatting information that are
> only relevant to obslog... and if you're looking for the formatting
> options, you'd have to scroll past a bunch of
> transformation-enablement options that are only relevant to evolve.
> Based on your log feedback above, I'm thinking #5 may make sense.
(5) sounds good to me, too. Thanks, both, for your thoughtfulness.