Thread (4 messages) 4 messages, 2 authors, 2021-09-20

Re: [PATCH 1/1] builtin/commit-graph.c: don't accept common --[no-]progress

From: Taylor Blau <hidden>
Date: 2021-09-20 15:03:06

On Mon, Sep 20, 2021 at 08:46:32AM -0400, Derrick Stolee wrote:
On 9/18/2021 12:02 PM, Taylor Blau wrote:
quoted
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@szeder.dev/ (local)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help