Michael J Gruber wrote: > Jonathan Nieder venit, vidit, dixit 02.09.2010 10:16: >> Therefore this seems wrong to me (except as a backward-compatibility >> measure). [...] > One heuristic, which I would have left for a later patch because of its > radicality (and I think we're in some phase of some rc something), is to > simply not do any checks when calling the viewers. This requires that > everything is prepended with "git-", which I see you have done in > builtin/help.c. Yep, I agree with you in all respects, including the need to do something else (like the patch you sent) for v1.7.3. > Still, none-command help pages will not show up with > "git help -a". So it's not a complete solution. I think of "git --help -a" as a more complete version of the list from "git --help" --- that is, it is explaining what subcommands are available for git. On the other hand, on platforms where "man -k git" is not available, as you mention it is the index to the manual. Maybe "git help" should check GIT_HTML_PATH to provide a more complete index on such platforms. Just musing. > Alternatively, load_command_list() etc. could simply fill up a third > list "other_pages" (with non-executables) so that "git help -a" could > list "other help pages" in addition to the commands. I don't think this > would require any renaming nor Documentation updates. Looks like you had a similar thought. > ??? I guess this patch makes sense only after a patch which renames all > gitfoo.txt to git-foo.txt. Well, there were ulterior motives to that patch: I keep on mistyping half-hyphenated manpage names like gitcvs-migration. I should have included some appropriate Makefile magic for compatibility symlinks for the old names. Hopefully at least the idea was clear. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html