Junio C Hamano wrote:
> "Victoria Dye via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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.
>
>
