On Fri, Aug 05 2022, Derrick Stolee wrote: > On 8/4/2022 2:27 AM, Ævar Arnfjörð Bjarmason wrote: >> >> On Thu, Aug 04 2022, Victoria Dye via GitGitGadget wrote: >> >>> From: Victoria Dye <vdye@xxxxxxxxxx> >>> >>> Create a 'git diagnose' builtin to generate a standalone zip archive of >>> repository diagnostics. >> >> It's good to have this as a built-in separate from "git bugreport", >> but... >> >>> +git-diagnose - Generate a zip archive of diagnostic information >> >> ...I'd really prefer for this not to squat on such a common name we >> might regret having reserved later for such very specific >> functionality. I'd think e.g. these would be better: >> >> git mk-diagnostics-zip >> >> Or maybe: >> >> git archive-interesting-for-report > > These are not realistic replacements. Maybe: git diagnose create-zip ? >> If I had to guess what a "git diagnose" did, I'd probably think: >> >> * It analyzes your config, and suggests redundancies/alternatives >> * It does some perf tests / heuritics, and e.g. suggests you turn on >> the commit-graph writing. > > These sound like great options to add in the future, such as: > > --perf-test: Run performance tests on your repository using different > Git config options and recommend certain settings. > > (This --perf-test option would be a great way to get wider adoption > of parallel checkout, since its optimal settings are so machine > dependent.) ... > The thing is, even if we did these other things, it would result in > some kind of document that summarizes the repository shape and features. > That kind of data is exactly what this version of 'git diagnose' does. I think a command like "git diagnose" that had options to do other unrelated stuff, but by default created a zip archive when given no options would be rather confusing. Yes, it makes sense to emit some human-readable summary, but to zip it up as well? That's something we just need for the "git bugreport" case... > For now, it leaves the human reader responsible for making decisions > based on those documents, but they have been incredibly helpful when we > are _diagnosing_ issues users are having with their repositories. This is orthagonal to what I'm pointing out. You're basically saying the user can just read the documentation to find out what this built-in does. That's true, what I'm pointing out is that it's unfortunate that such highly specific functionality is squatting on such a short & generic name, but just e.g. adding a "create-zip" sub-command would address that.
