If set in git-config, help.htmlpath overrides system_path(GIT_HTML_PATH)
which was compiled in. This allows users to repoint system-wide git at
their own copy of the documentation without recompiling.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 1cc8af0 "help: use HTML as the default help format on Windows"
lost the ability to make use of the help.format config value by forcing
the use of a compiled in default if no command-line argument was provided.
This commit restores the use of the help.format value if one is
available, overriding the compiled default.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'git help $cmd' is run without a format option (e.g. -w), the
'man' format is always used. On some platforms, however, manual page
viewers are not often available.
Introduce DEFAULT_HELP_FORMAT make variable in order to allow the
default format configurable at compile time, and set it to HTML when
compiling on Windows (but not Cygwin).
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A couple of commands learn --column option to produce columnar output.
By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1)
* nd/columns:
tag: add --column
column: support piping stdout to external git-column process
status: add --column
branch: add --column
help: reuse print_columns() for help -a
column: add dense layout support
t9002: work around shells that are unable to set COLUMNS to 1
column: add columnar layout
Stop starting pager recursively
Add column layout skeleton and git-column
"help -a" also respects column.ui (and column.help if presents)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to underline a header text, like this:
This is a header
----------------
content...
But calculating text length so that the dashes align with the text
could get complicated because the text could be in any charset in
translated Git.
There is no point to use this pseudo underline; simply a blank
line would do and it even makes it easier to read:
This is a header
content...
While at it, give translators more context to translate, e.g.
e.g. "git commands available..." instead of "%s available..."
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch also marks most common commands' synopsis for translation
so that "git help" gives a friendly listing.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The NULL sentinel argument to the execl*() family of calls must be
cast to (char *), as otherwise:
- platforms where NULL is just 0 (not (void *)) would pass an int
- (admittedly esoteric) platforms where NULL is (void *)0 and (void *)
and (char *) have different memory layouts would pass the wrong kind
of pointer
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX
5.1 fails to compile git.
enum style is inconsistent already, with some enums declared on one
line, some over 3 lines with the enum values all on the middle line,
sometimes with 1 enum value per line... and independently of that the
trailing comma is sometimes present and other times absent, often
mixing with/without trailing comma styles in a single file, and
sometimes in consecutive enum declarations.
Clearly, omitting the comma is the more portable style, and this patch
changes all enum declarations to use the portable omitted dangling
comma style consistently.
Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of
[torvalds@nehalem git]$ em buil<tab>
Display all 180 possibilities? (y or n)
[torvalds@nehalem git]$ em builtin-sh
builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c
builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o
[torvalds@nehalem git]$ em builtin-shor<tab>
builtin-shortlog.c builtin-shortlog.o
[torvalds@nehalem git]$ em builtin-shortlog.c
you get
[torvalds@nehalem git]$ em buil<tab> [type]
builtin/ builtin.h
[torvalds@nehalem git]$ em builtin [auto-completes to]
[torvalds@nehalem git]$ em builtin/sh<tab> [type]
shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o
[torvalds@nehalem git]$ em builtin/sho [auto-completes to]
[torvalds@nehalem git]$ em builtin/shor<tab> [type]
shortlog.c shortlog.o
[torvalds@nehalem git]$ em builtin/shortlog.c
which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.
NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead. I think bash has some cut-off
around 100 choices or something.
So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion. But you can
simulate that by using 'ls' instead, or something similar.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
