Merge branch 'ma/pager-per-subcommand-action'
The "tag.pager" configuration variable was useless for those who actually create tag objects, as it interfered with the use of an editor. A new mechanism has been introduced for commands to enable pager depending on what operation is being carried out to fix this, and then "git tag -l" is made to run pager by default. * ma/pager-per-subcommand-action: git.c: ignore pager.* when launching builtin as dashed external tag: change default of `pager.tag` to "on" tag: respect `pager.tag` in list-mode only t7006: add tests for how git tag paginates git.c: provide setup_auto_pager() git.c: let builtins opt for handling `pager.foo` themselves builtin.h: take over documentation from api-builtin.txt
This commit is contained in:
@ -1,73 +0,0 @@
|
||||
builtin API
|
||||
===========
|
||||
|
||||
Adding a new built-in
|
||||
---------------------
|
||||
|
||||
There are 4 things to do to add a built-in command implementation to
|
||||
Git:
|
||||
|
||||
. Define the implementation of the built-in command `foo` with
|
||||
signature:
|
||||
|
||||
int cmd_foo(int argc, const char **argv, const char *prefix);
|
||||
|
||||
. Add the external declaration for the function to `builtin.h`.
|
||||
|
||||
. Add the command to the `commands[]` table defined in `git.c`.
|
||||
The entry should look like:
|
||||
|
||||
{ "foo", cmd_foo, <options> },
|
||||
+
|
||||
where options is the bitwise-or of:
|
||||
|
||||
`RUN_SETUP`::
|
||||
If there is not a Git directory to work on, abort. If there
|
||||
is a work tree, chdir to the top of it if the command was
|
||||
invoked in a subdirectory. If there is no work tree, no
|
||||
chdir() is done.
|
||||
|
||||
`RUN_SETUP_GENTLY`::
|
||||
If there is a Git directory, chdir as per RUN_SETUP, otherwise,
|
||||
don't chdir anywhere.
|
||||
|
||||
`USE_PAGER`::
|
||||
|
||||
If the standard output is connected to a tty, spawn a pager and
|
||||
feed our output to it.
|
||||
|
||||
`NEED_WORK_TREE`::
|
||||
|
||||
Make sure there is a work tree, i.e. the command cannot act
|
||||
on bare repositories.
|
||||
This only makes sense when `RUN_SETUP` is also set.
|
||||
|
||||
. Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
|
||||
|
||||
Additionally, if `foo` is a new command, there are 3 more things to do:
|
||||
|
||||
. Add tests to `t/` directory.
|
||||
|
||||
. Write documentation in `Documentation/git-foo.txt`.
|
||||
|
||||
. Add an entry for `git-foo` to `command-list.txt`.
|
||||
|
||||
. Add an entry for `/git-foo` to `.gitignore`.
|
||||
|
||||
|
||||
How a built-in is called
|
||||
------------------------
|
||||
|
||||
The implementation `cmd_foo()` takes three parameters, `argc`, `argv,
|
||||
and `prefix`. The first two are similar to what `main()` of a
|
||||
standalone command would be called with.
|
||||
|
||||
When `RUN_SETUP` is specified in the `commands[]` table, and when you
|
||||
were started from a subdirectory of the work tree, `cmd_foo()` is called
|
||||
after chdir(2) to the top of the work tree, and `prefix` gets the path
|
||||
to the subdirectory the command started from. This allows you to
|
||||
convert a user-supplied pathname (typically relative to that directory)
|
||||
to a pathname relative to the top of the work tree.
|
||||
|
||||
The return value from `cmd_foo()` becomes the exit status of the
|
||||
command.
|
Reference in New Issue
Block a user