development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-10-28 19:25:47 +00:00
Code Issues Projects Releases Packages Wiki Activity
git/Documentation/git-var.txt

106 lines
3.1 KiB
Text
Raw Normal View History

[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
git-var(1)
Fix up "make doc" Fix 'git-var.txt' and use "-b xhtml11" instead of "-b css-embedded" to make asciidoc 7.0.1 happy.
2005-07-15 21:57:09 +00:00
==========
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
NAME
----
Documentation: the name of the system is 'Git', not 'git' Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21 19:17:53 +00:00
git-var - Show a Git logical variable
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
SYNOPSIS
--------
Documentation: use [verse] for SYNOPSIS sections The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-02 02:38:26 +00:00
[verse]
doc txt & -h consistency: correct padding around "[]()" The whitespace padding of alternatives should be of the form "[-f | --force]" not "[-f|--force]". Likewise we should not have padding before the first option, so "(--all | <pack-filename>...)" is correct, not "( --all | <pack-filename>... )". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-13 15:39:06 +00:00
'git var' (-l | <variable>)
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
DESCRIPTION
-----------
var: do not print usage() with a correct invocation Before, git-var could print usage() even if the command was invoked correctly with a variable defined in git_vars -- provided that its read() function returned NULL. Now, we only print usage() only if it was called with a logical variable that wasn't defined -- regardless of read(). Since we now know the variable is valid when we call read_var(), we can avoid printing usage() here (and exiting with code 129) and instead exit quietly with code 1. While exiting with a different code can be a breaking change, it's far better than changing the exit status more generally from 'failure' to 'success'. Signed-off-by: Sean Allred <allred.sean@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-11-26 14:17:56 +00:00
Prints a Git logical variable. Exits with code 1 if the variable has
no value.
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
[PATCH] Random documentation fixes The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 17:16:30 +00:00
OPTIONS
-------
-l::
Document git-var -l listing also configuration variables Signed-off-by: Petr Baudis <pasky@suse.cz>
2006-04-24 22:59:28 +00:00
Cause the logical variables to be listed. In addition, all the
Documentation: the name of the system is 'Git', not 'git' Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21 19:17:53 +00:00
variables of the Git configuration file .git/config are listed
Deprecate usage of git-var -l for getting config vars list This has been an unfortunate sideway in the git API evolution. We use git-repo-config for all the other .git/config interaction so let's also use git-repo-config -l for the variable listing. Signed-off-by: Petr Baudis <pasky@suse.cz>
2006-04-24 22:59:30 +00:00
as well. (However, the configuration variables listing functionality
Documentation: format full commands in typewriter font Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2010-01-07 16:49:12 +00:00
is deprecated in favor of `git config -l`.)
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
doc: keep first level section header in upper case When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-30 15:35:33 +00:00
EXAMPLES
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
--------
Documentation: be consistent about "git-" versus "git " Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-30 06:09:04 +00:00
$ git var GIT_AUTHOR_IDENT
[PATCH] Random documentation fixes The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 17:16:30 +00:00
Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
VARIABLES
doc: keep first level section header in upper case When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-30 15:35:33 +00:00
---------
[PATCH] Random documentation fixes The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 17:16:30 +00:00
GIT_AUTHOR_IDENT::
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
The author of a piece of code.
[PATCH] Random documentation fixes The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 17:16:30 +00:00
GIT_COMMITTER_IDENT::
Documentation: the name of the system is 'Git', not 'git' Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21 19:17:53 +00:00
The person who put a piece of code into Git.
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
Teach git var about GIT_EDITOR Expose the command used by launch_editor() for scripts to use. This should allow one to avoid searching for a proper editor separately in each command. git_editor(void) uses the logic to decide which editor to use that used to live in launch_editor(). The function returns NULL if there is no suitable editor; the caller is expected to issue an error message when appropriate. launch_editor() uses git_editor() and gives the error message the same way as before when EDITOR is not set. "git var GIT_EDITOR" gives the editor name, or an error message when there is no appropriate one. "git var -l" gives GIT_EDITOR=name only if there is an appropriate editor. Originally-submitted-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:01:27 +00:00
GIT_EDITOR::
Documentation: the name of the system is 'Git', not 'git' Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21 19:17:53 +00:00
Text editor for use by Git commands. The value is meant to be
Teach git var about GIT_EDITOR Expose the command used by launch_editor() for scripts to use. This should allow one to avoid searching for a proper editor separately in each command. git_editor(void) uses the logic to decide which editor to use that used to live in launch_editor(). The function returns NULL if there is no suitable editor; the caller is expected to issue an error message when appropriate. launch_editor() uses git_editor() and gives the error message the same way as before when EDITOR is not set. "git var GIT_EDITOR" gives the editor name, or an error message when there is no appropriate one. "git var -l" gives GIT_EDITOR=name only if there is an appropriate editor. Originally-submitted-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:01:27 +00:00
interpreted by the shell when it is used. Examples: `~/bin/vi`,
`$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe"
--nofork`. The order of preference is the `$GIT_EDITOR`
environment variable, then `core.editor` configuration, then
var doc: default editor and pager are configurable at build time Some distributors customize the fallback pager and editor used by git commands when the user has not indicated a preference via the core.editor/core.pager configuration or GIT_EDITOR, GIT_PAGER, VISUAL, EDITOR, and PAGER environment variables, and git's build system provides DEFAULT_PAGER and DEFAULT_EDITOR makefile settings to help them with that (see v1.6.6-rc0~24, 2009-11-20). Unfortunately those compile-time settings do not affect the documentation, so the uninitiated user who tries to understand git by reading the git-var(1) manpage can easily be confused when git falls back to 'nano' and 'more' instead of 'vi' and 'less'. Even if the distributor patches the distributed docs to reflect the new default, the user may read the official documentation from the git-htmldocs repository online and be confused in the same way. Add a few words stating that the defaults are customizable at compile time to make the behavior crystal clear. Reported-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 08:42:34 +00:00
`$VISUAL`, then `$EDITOR`, and then the default chosen at compile
time, which is usually 'vi'.
var doc: advertise current DEFAULT_PAGER and DEFAULT_EDITOR settings Document the default pager and editor chosen at compile time in the git-var(1) manpage so users curious about what command _this_ copy of git will fall back to when EDITOR, VISUAL, and PAGER are unset can find the answer quickly. In builds leaving those settings uncustomized, this patch makes the manpage continue to say "usually vi" and "usually less" so the formatted documentation is usable for a wide audience including users of custom builds that change those settings. If you would like your copy of the docs to be less noncommittal, you will need to set DEFAULT_PAGER=less and DEFAULT_EDITOR=vi explicitly. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 08:44:53 +00:00
ifdef::git-default-editor[]
The build you are using chose '{git-default-editor}' as the default.
endif::git-default-editor[]
Teach git var about GIT_EDITOR Expose the command used by launch_editor() for scripts to use. This should allow one to avoid searching for a proper editor separately in each command. git_editor(void) uses the logic to decide which editor to use that used to live in launch_editor(). The function returns NULL if there is no suitable editor; the caller is expected to issue an error message when appropriate. launch_editor() uses git_editor() and gives the error message the same way as before when EDITOR is not set. "git var GIT_EDITOR" gives the editor name, or an error message when there is no appropriate one. "git var -l" gives GIT_EDITOR=name only if there is an appropriate editor. Originally-submitted-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:01:27 +00:00
var: add GIT_SEQUENCE_EDITOR variable The editor program used by Git when editing the sequencer "todo" file is determined by examining a few environment variables and also affected by configuration variables. Introduce "git var GIT_SEQUENCE_EDITOR" to give users access to the final result of the logic without having to know the exact details. This is very similar in spirit to 44fcb497 (Teach git var about GIT_EDITOR, 2009-11-11) that introduced "git var GIT_EDITOR". Signed-off-by: Sean Allred <allred.sean@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-17 23:09:59 +00:00
GIT_SEQUENCE_EDITOR::
Text editor used to edit the 'todo' file while running `git rebase
-i`. Like `GIT_EDITOR`, the value is meant to be interpreted by
the shell when it is used. The order of preference is the
`$GIT_SEQUENCE_EDITOR` environment variable, then
`sequence.editor` configuration, and then the value of `git var
GIT_EDITOR`.
Teach git var about GIT_PAGER Expose the command found by setup_pager() for scripts to use. Scripts can use this to avoid repeating the logic to look for a proper pager in each command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:41:27 +00:00
GIT_PAGER::
Documentation: the name of the system is 'Git', not 'git' Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21 19:17:53 +00:00
Text viewer for use by Git commands (e.g., 'less'). The value
Teach git var about GIT_PAGER Expose the command found by setup_pager() for scripts to use. Scripts can use this to avoid repeating the logic to look for a proper pager in each command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:41:27 +00:00
is meant to be interpreted by the shell. The order of preference
is the `$GIT_PAGER` environment variable, then `core.pager`
var doc: default editor and pager are configurable at build time Some distributors customize the fallback pager and editor used by git commands when the user has not indicated a preference via the core.editor/core.pager configuration or GIT_EDITOR, GIT_PAGER, VISUAL, EDITOR, and PAGER environment variables, and git's build system provides DEFAULT_PAGER and DEFAULT_EDITOR makefile settings to help them with that (see v1.6.6-rc0~24, 2009-11-20). Unfortunately those compile-time settings do not affect the documentation, so the uninitiated user who tries to understand git by reading the git-var(1) manpage can easily be confused when git falls back to 'nano' and 'more' instead of 'vi' and 'less'. Even if the distributor patches the distributed docs to reflect the new default, the user may read the official documentation from the git-htmldocs repository online and be confused in the same way. Add a few words stating that the defaults are customizable at compile time to make the behavior crystal clear. Reported-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 08:42:34 +00:00
configuration, then `$PAGER`, and then the default chosen at
compile time (usually 'less').
var doc: advertise current DEFAULT_PAGER and DEFAULT_EDITOR settings Document the default pager and editor chosen at compile time in the git-var(1) manpage so users curious about what command _this_ copy of git will fall back to when EDITOR, VISUAL, and PAGER are unset can find the answer quickly. In builds leaving those settings uncustomized, this patch makes the manpage continue to say "usually vi" and "usually less" so the formatted documentation is usable for a wide audience including users of custom builds that change those settings. If you would like your copy of the docs to be less noncommittal, you will need to set DEFAULT_PAGER=less and DEFAULT_EDITOR=vi explicitly. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-31 08:44:53 +00:00
ifdef::git-default-pager[]
The build you are using chose '{git-default-pager}' as the default.
endif::git-default-pager[]
Teach git var about GIT_PAGER Expose the command found by setup_pager() for scripts to use. Scripts can use this to avoid repeating the logic to look for a proper pager in each command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-31 01:41:27 +00:00
var: add GIT_DEFAULT_BRANCH variable Introduce the logical variable GIT_DEFAULT_BRANCH which represents the the default branch name that will be used by "git init". Currently this variable is equivalent to git config init.defaultbranch || 'master' This however will break if at one point the default branch is changed as indicated by `default_branch_name_advice` in `refs.c`. By providing this command ahead of time users of git can make their code forward-compatible. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03 20:17:02 +00:00
GIT_DEFAULT_BRANCH::
The name of the first branch created in newly initialized repositories.
var: add support for listing the shell On most Unix systems, finding a suitable shell is easy: one simply uses "sh" with an appropriate PATH value. However, in many Windows environments, the shell is shipped alongside Git, and it may or may not be in PATH, even if Git is. In such an environment, it can be very helpful to query Git for the shell it's using, since other tools may want to use the same shell as well. To help them out, let's add a variable, GIT_SHELL_PATH, that points to the location of the shell. On Unix, we know our shell must be executable to be functional, so assume that the distributor has correctly configured their environment, and use that as a basic test. On Git for Windows, we know that our shell will be one of a few fixed values, all of which end in "sh" (such as "bash"). This seems like it might be a nice test on Unix as well, since it is customary for all shells to end in "sh", but there probably exist such systems that don't have such a configuration, so be careful here not to break them. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-27 16:18:57 +00:00
GIT_SHELL_PATH::
The path of the binary providing the POSIX shell for commands which use the shell.
var: add attributes files locations Currently, there are some programs which would like to read and parse the gitattributes files at the global or system levels. However, it's not always obvious where these files live, especially for the system file, which may have been hard-coded at compile time or computed dynamically based on the runtime prefix. It's not reasonable to expect all callers of Git to intuitively know where the Git distributor or user has configured these locations to be, so add some entries to allow us to determine their location. Honor the GIT_ATTR_NOSYSTEM environment variable if one is specified. Expose the accessor functions in a way that we can reuse them from within the var code. In order to make our paths consistent on Windows and also use the same form as paths use in "git rev-parse", let's normalize the path before we return it. This results in Windows-style paths that use slashes, which is convenient for making our tests function in a consistent way across platforms. Note that this requires that some of our values be freed, so let's add a flag about whether the value needs to be freed and use it accordingly. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-27 16:19:01 +00:00
GIT_ATTR_SYSTEM::
The path to the system linkgit:gitattributes[5] file, if one is enabled.
GIT_ATTR_GLOBAL::
The path to the global (per-user) linkgit:gitattributes[5] file.
var: add config file locations Much like with attributes files, sometimes programs would like to know the location of configuration files at the global or system levels. However, it isn't always clear where these may live, especially for the system file, which may have been hard-coded at compile time or computed dynamically based on the runtime prefix. Since other parties cannot intuitively know how Git was compiled and where it looks for these files, help them by providing variables that can be queried. Because we have multiple paths for global config values, print them in order from highest to lowest priority, and be sure to split on newlines so that "git var -l" produces two entries for the global value. However, be careful not to split all values on newlines, since our editor values could well contain such characters, and we don't want to split them in such a case. Note in the documentation that some values may contain multiple paths and that callers should be prepared for that fact. This helps people write code that will continue to work in the event we allow multiple items elsewhere in the future. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-27 16:19:02 +00:00
GIT_CONFIG_SYSTEM::
The path to the system configuration file, if one is enabled.
GIT_CONFIG_GLOBAL::
The path to the global (per-user) configuration files, if any.
Most path values contain only one value. However, some can contain multiple
values, which are separated by newlines, and are listed in order from highest to
lowest priority. Callers should be prepared for any such path value to contain
multiple items.
Note that paths are printed even if they do not exist, but not if they are
disabled by other environment variables.
Manual subsection to refer to other pages is SEE ALSO Consistently say so in all caps as it is customary to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28 23:55:27 +00:00
SEE ALSO
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
--------
Documentation: rename gitlink macro to linkgit Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-29 06:20:38 +00:00
linkgit:git-commit-tree[1]
linkgit:git-tag[1]
linkgit:git-config[1]
[PATCH] Add git-var a tool for reading interesting git variables. Sharing code between shell scripts and C is a challenge. The program git-var allows us to have a set of named values that a shell script can interrogate and a normal C program can simply call the functions that compute them. Allowing sharing when computing plain test values. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 00:55:09 +00:00
GIT
---
documentation: move git(7) to git(1) As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06 07:07:32 +00:00
Part of the linkgit:git[1] suite
Reference in a new issue Copy permalink