On Mon, Sep 20, 2021 at 08:46:32AM -0400, Derrick Stolee wrote: > On 9/18/2021 12:02 PM, Taylor Blau wrote: > > Since we haven't released a version of Git that supports --[no-]progress > > as a top-level option for `git commit-graph`, let's remove it. > > I agree that is the best way to respond right now. Moving it to > top-level will need more work. SZEDER posted a patch in [1] which would allow us to define a top-level `--[no-]progress` option for the commit-graph builtin. (I'm assuming that you meant the builtin when you said "top-level", and not git itself). But see some of his commentary above the patch in [1] about why we may want to avoid applying something like his patch, in particular: In general, even when all subcommands of a git command understand a particular --option, that does not mean that it's a good idea to teach that option to that git command. E.g. what if we later add another subcommand for which that --option doesn't make any sense? And from the quoted discussion above it seems that teaching 'git commit-graph' the '--progress' option was not intentional at all. This patch has the added advantage that we can always "go back" to SZEDER's approach and make `--[no-]progress` work as an option to `git commit-graph`. But doing this buys us some time to make sure that is the approach we want to take. Thanks, Taylor [1]: https://lore.kernel.org/git/20210917211337.GC2118053@xxxxxxxxxx/
