Ævar Arnfjörð Bjarmason wrote: > On Sun, Jul 04 2021, Felipe Contreras wrote: > > I think there's some value in that idea but that doesn't solve the same > > problem my suggestion solves. Basically there's too many commands in > > `man git`. Splitting the git binary would allow us to only put the > > important commands in `man git`. > > > > I think having too many commands overwhelms many newcomers, because they > > don't know which it's important for them to learn and which are > > basically noise. > > I'm very much for the idea of a cleanup of "man git", but I don't think > we need to introduce a git-tool(1) for that. Indeed, it's not *necessary*, but it would help tremendously. > E.g. "man perl" is a good example of where we should be > headed. I.e. right off the bat in "man git" we have a long listing of > command-line options to git itself, things like --exec-path and > --no-optional-locks etc. are useful to almost no casual user. > > We should really split everything except a passing mention of -p, -P, -c > etc. into a "man gitrun" or something (just like perl has "man > perlrun"), ditto the whole "ENVIRONMENT VARIABLES" section. I like that. For the record zsh also splits man pages that way. I would prefer `git-run` (or `git-core`) though, althought if somebody at some point wants to create such a built-in that would be problematic. -- Felipe Contreras
