Re: [PATCH v2 00/10] Generalize 'scalar diagnose' into 'git diagnose' and 'git bugreport --diagnose'

From: Victoria Dye <vdye@github.com>
Date: Aug 9, 2022, 16:17 UTC
Message-ID: <82af0381-ecdc-adf4-1339-ec35c18118a1@github.com>
In-Reply-To: <xmqqwnbn6i0v.fsf@gitster.g>

Junio C Hamano wrote:

Show 13 quoted lines

> "Victoria Dye via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>>  * (Almost) entirely redesigned the UI for generating diagnostics. The new
>>    approach avoids cluttering 'git bugreport' with a mode that doesn't
>>    actually generate a report. Now, there are distinct options for different
>>    use cases: generating extra diagnostics with a bug report ('git bugreport
>>    --diagnose') and generating diagnostics for personal debugging/addition
>>    to an existing bug report ('git diagnose').
> 
> An additional command gives us far more design flexibility, and in
> this case I think it may be worth it.  It has a risk of confusing
> users between "git bugreport --diag" and "git diagnose --report" a
> way to send a report with diagnostic information, though.

This is an interesting point and something I think users could plausibly run into. I can think of a few of ways to address that:

1. Do nothing, wait for feedback from users.
2. Create hidden option(s) '--report' and/or '--bugreport' in 'git diagnose'
   that trigger a warning (or advice?) along the lines of "did you mean 'git
   bugreport --diagnose'?" and exit with 'usage()'.
3. Create visible options '--report' and/or '--bugreport' in 'git diagnose'
   that invoke 'git bugreport --diagnose'.

I'm leaning towards option 2, but I'd also understand not wanting to clutter builtins with options it *doesn't* use for the sake of advising a user.

> 
>