path: root/Documentation/git-rev-parse.txt
AgeCommit message (Collapse)Author
2010-01-31Fix typos in technical documentation.Ralf Wildenhues
Signed-off-by: Ralf Wildenhues <> Signed-off-by: Junio C Hamano <>
2010-01-23Merge branch 'il/rev-glob'Junio C Hamano
* il/rev-glob: Documentation: improve description of --glob=pattern and friends rev-parse --branches/--tags/--remotes=pattern rev-parse --glob
2010-01-23Merge branch 'js/refer-upstream'Junio C Hamano
* js/refer-upstream: Teach @{upstream} syntax to strbuf_branchanme() t1506: more test for @{upstream} syntax Introduce <branch>@{upstream} notation
2010-01-22Documentation: improve description of --glob=pattern and friendsThomas Rast
Consolidate the descriptions of --branches, --tags and --remotes a bit, to make it less repetitive. Improve the grammar a bit, and spell out the meaning of the 'append /*' rule. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2010-01-21Merge remote branch 'remotes/trast-doc/for-next'Junio C Hamano
* remotes/trast-doc/for-next: Documentation: spell 'git cmd' without dash throughout Documentation: format full commands in typewriter font Documentation: warn prominently against merging with dirty trees Documentation/git-merge: reword references to "remote" and "pull" Conflicts: Documentation/config.txt Documentation/git-config.txt Documentation/git-merge.txt
2010-01-20rev-parse --branches/--tags/--remotes=patternIlari Liusvaara
Since local branch, tags and remote tracking branch namespaces are most often used, add shortcut notations for globbing those in manner similar to --glob option. With this, one can express the "what I have but origin doesn't?" as: 'git log --branches --not --remotes=origin' Original-idea-by: Johannes Sixt <> Signed-off-by: Ilari Liusvaara <> Signed-off-by: Junio C Hamano <>
2010-01-20rev-parse --globIlari Liusvaara
Add --glob=<glob-pattern> option to rev-parse and everything that accepts its options. This option matches all refs that match given shell glob pattern (complete with some DWIM logic). Example: 'git log --branches --not --glob=remotes/origin' To show what you have that origin doesn't. Signed-off-by: Ilari Liusvaara <> Signed-off-by: Junio C Hamano <>
2010-01-12Introduce <branch>@{upstream} notationJohannes Schindelin
A new notation '<branch>@{upstream}' refers to the branch <branch> is set to build on top of. Missing <branch> (i.e. '@{upstream}') defaults to the current branch. This allows you to run, for example, for l in list of local branches do git log --oneline --left-right $l...$l@{upstream} done to inspect each of the local branches you are interested in for the divergence from its upstream. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2010-01-12Add 'git rev-parse --show-toplevel' option.Steven Drake
Shows the absolute path of the top-level working directory. Signed-off-by: Steven Drake <> Signed-off-by: Junio C Hamano <>
2010-01-10Documentation: spell 'git cmd' without dash throughoutThomas Rast
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2009-06-14parse-opt: make PARSE_OPT_STOP_AT_NON_OPTION available to git rev-parseUwe Kleine-König
Signed-off-by: Uwe Kleine-König <> Signed-off-by: Junio C Hamano <>
2009-05-10rev-parse: add --sq-quote to shell quote argumentsChristian Couder
Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2009-04-29parseopt: fix documentation for --keep-dashdashUwe Kleine-König
Signed-off-by: Uwe Kleine-König <> Signed-off-by: Junio C Hamano <>
2009-04-13rev-parse: --abbrev-ref option to shorten ref nameBert Wesarg
This applies the shorten_unambiguous_ref function to the object name. Default mode is controlled by core.warnAmbiguousRefs. Else it is given as optional argument to --abbrev-ref={strict|loose}. This should be faster than 'git for-each-ref --format="%(refname:short)" <ref>' for single refs. Signed-off-by: Bert Wesarg <> Signed-off-by: Junio C Hamano <>
2009-03-17Documentation: remove extra quoting/emphasis around literal textsChris Johnsen
If literal text (asciidoc `...`) can be rendered in a differently from normal text for each output format (man, HTML), then we do not need extra quotes or other wrapping around inline literal text segments. config.txt Change '`...`' to `...`. In asciidoc, the single quotes provide emphasis, literal text should be distintive enough. Change "`...`" to `...`. These double quotes do not work if present in the described config value, so drop them. git-checkout.txt Change "`...`" to `...` or `"..."`. All instances are command line argument examples. One "`-`" becomes `-`. Two others are involve curly braces, so move the double quotes inside the literal region to indicate that they might need to be quoted on the command line of certain shells (tcsh). git-merge.txt Change "`...`" to `...`. All instances are used to describe merge conflict markers. The quotes should are not important. git-rev-parse.txt Change "`...`" to `...`. All instances are around command line arguments where no in-shell quoting should be necessary. gitcli.txt Change `"..."` to `...`. All instances are around command line examples or single command arguments. They do not semanticly belong inside the literal text, and they are not needed outside it. glossary-content.txt user-manual.txt Change "`...`" to `...`. All instances were around command lines. Signed-off-by: Chris Johnsen <> Signed-off-by: Junio C Hamano <>
2009-01-18sha1_name: support @{-N} syntax in get_sha1()Thomas Rast
Let get_sha1() parse the @{-N} syntax, with docs and tests. Note that while @{-1}^2, @{-2}~5 and such are supported, @{-1}@{1} is currently not allowed. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2008-07-30Documentation/git-rev-parse.txt: update for new git-describe output formatCesar Eduardo Barros
Signed-off-by: Cesar Eduardo Barros <> Signed-off-by: Junio C Hamano <>
2008-07-21Update my e-mail addressJunio C Hamano
The old address is still getting mails from gitters. Signed-off-by: Junio C Hamano <>
2008-07-09Documentation: update sections on naming revisions and revision rangesJunio C Hamano
Various *_HEAD pseudo refs were not documented in any central place. Especially since we may be teaching rebase and am to record ORIG_HEAD, it would be a good time to do so. While at it, reword the explanation on r1..r2 notation to reduce confusion. Signed-off-by: Junio C Hamano <>
2008-07-07Merge branch 'maint'Junio C Hamano
* maint: Fix grammar in git-rev-parse(1).
2008-07-07Fix grammar in git-rev-parse(1).Mikael Magnusson
Signed-off-by: Junio C Hamano <>
2008-07-05manpages: italicize git command names (which were in teletype font)Jonathan Nieder
The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation formatting and cleanupJonathan Nieder
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation: be consistent about "git-" versus "git "Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2008-06-30doc/rev-parse: clarify reflog vs --until for specifying revisionsJeff King
The rev-parse manpage introduces the branch@{date} syntax, and mentions the reflog specifically. However, new users may not be familiar with the distinction between the reflog and the commit date, so let's help them out with a "you may be interested in --until" pointer. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsStephan Beyer
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <> Signed-off-by: Junio C Hamano <>
2008-06-06documentation: move git(7) to git(1)Christian Couder
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 <> Signed-off-by: Junio C Hamano <>
2008-05-27Merge branch 'maint'Junio C Hamano
* maint: Documentation: fix graph in git-rev-parse.txt show-branch --current: do not barf on detached HEAD
2008-05-27Documentation: fix graph in git-rev-parse.txtMichele Ballabio
Preformatted html and man pages show a mangled graph, caused by a backslash. Commit f1ec6b22a8c1ab1cca0f1875f85aea5d2434e5a6 fixed this same issue, but it seems that new versions of the Asciidoc toolchain changed their behaviour. Signed-off-by: Michele Ballabio <> Signed-off-by: Junio C Hamano <>
2008-05-21Documentation: rev-parse: add a few "--verify" and "--default" examplesChristian Couder
Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2008-05-05Documentation: rename "hooks.txt" to "githooks.txt" and make it a man pageChristian Couder
Also now "gitcli(5)" becomes "gitcli(7)". Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2008-04-27rev-parse: teach "--verify" to be quiet when using "-q" or "--quiet"Christian Couder
Currently "git rev-parse --verify <something>" is often used with its error output redirected to /dev/null. This patch makes it easier to do that. The -q|--quiet option is designed to work the same way as it does for "git symbolic-ref". Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2008-03-02parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --parseoptPierre Habouzit
Signed-off-by: Pierre Habouzit <> Signed-off-by: Junio C Hamano <>
2008-01-31git rev-parse manpage: spelling fixMiklos Vajna
Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>
2008-01-30fix doc typosJim Meyering
Signed-off-by: Jim Meyering <> Signed-off-by: Junio C Hamano <>
2008-01-07Documentation: rename gitlink macro to linkgitDan McGee
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 <> Signed-off-by: Junio C Hamano <>
2008-01-07git-rev-parse --symbolic-full-nameJunio C Hamano
The plumbing level can understand that the user meant "refs/heads/master" when the user says "master" or "heads/master", but there is no easy way for the scripts to figure it out without duplicating the dwim_ref() logic. Signed-off-by: Junio C Hamano <>
2007-11-06Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.Pierre Habouzit
Signed-off-by: Pierre Habouzit <> Signed-off-by: Junio C Hamano <>
2007-08-20Document what the stage numbers in the :$n:path syntax mean.Steven Grimm
The git-rev-parse manpage talks about the :$n:path notation (buried deep in a list of other syntax) but it just says $n is a "stage number" -- someone who is not familiar with the internals of git's merge implementation is never going to be able to figure out that "1", "2", and "3" means. Signed-off-by: Junio C Hamano <>
2007-08-10Fix an illustration in git-rev-parse.txtJunio C Hamano
This hides the backslash at the end of line from AsciiDoc toolchain by introducing a trailing whitespace on one line in an illustration in git-rev-parse.txt. Signed-off-by: Junio C Hamano <>
2007-07-01Merge branch 'ei/worktree+filter'Junio C Hamano
* ei/worktree+filter: filter-branch: always export GIT_DIR if it is set setup_git_directory: fix segfault if repository is found in cwd test GIT_WORK_TREE extend rev-parse test for --is-inside-work-tree Use new semantics of is_bare/inside_git_dir/inside_work_tree introduce GIT_WORK_TREE to specify the work tree test git rev-parse rev-parse: introduce --is-bare-repository rev-parse: document --is-inside-git-dir
2007-06-16Document git rev-parse --is-inside-git-dirJakub Narebski
Signed-off-by: Jakub Narebski <> Signed-off-by: Junio C Hamano <>
2007-06-07War on whitespaceJunio C Hamano
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <>
2007-06-06introduce GIT_WORK_TREE to specify the work treeMatthias Lederhofer
setup_gdg is used as abbreviation for setup_git_directory_gently. The work tree can be specified using the environment variable GIT_WORK_TREE and the config option core.worktree (the environment variable has precendence over the config option). Additionally there is a command line option --work-tree which sets the environment variable. setup_gdg does the following now: GIT_DIR unspecified repository in .git directory parent directory of the .git directory is used as work tree, GIT_WORK_TREE is ignored GIT_DIR unspecified repository in cwd GIT_DIR is set to cwd see the cases with GIT_DIR specified what happens next and also see the note below GIT_DIR specified GIT_WORK_TREE/core.worktree unspecified cwd is used as work tree GIT_DIR specified GIT_WORK_TREE/core.worktree specified the specified work tree is used Note on the case where GIT_DIR is unspecified and repository is in cwd: GIT_WORK_TREE is used but is_inside_git_dir is always true. I did it this way because setup_gdg might be called multiple times (e.g. when doing alias expansion) and in successive calls setup_gdg should do the same thing every time. Meaning of is_bare/is_inside_work_tree/is_inside_git_dir: (1) is_bare_repository A repository is bare if core.bare is true or core.bare is unspecified and the name suggests it is bare (directory not named .git). The bare option disables a few protective checks which are useful with a working tree. Currently this changes if a repository is bare: updates of HEAD are allowed git gc packs the refs the reflog is disabled by default (2) is_inside_work_tree True if the cwd is inside the associated working tree (if there is one), false otherwise. (3) is_inside_git_dir True if the cwd is inside the git directory, false otherwise. Before this patch is_inside_git_dir was always true for bare repositories. When setup_gdg finds a repository git_config(git_default_config) is always called. This ensure that is_bare_repository makes use of core.bare and does not guess even though core.bare is specified. inside_work_tree and inside_git_dir are set if setup_gdg finds a repository. The is_inside_work_tree and is_inside_git_dir functions will die if they are called before a successful call to setup_gdg. Signed-off-by: Matthias Lederhofer <> Signed-off-by: Junio C Hamano <>
2007-06-06rev-parse: introduce --is-bare-repositoryMatthias Lederhofer
Signed-off-by: Matthias Lederhofer <> Signed-off-by: Junio C Hamano <>
2007-06-06rev-parse: document --is-inside-git-dirMatthias Lederhofer
Signed-off-by: Matthias Lederhofer <> Signed-off-by: Junio C Hamano <>
2007-05-10SPECIFYING RANGES typo fix: it it => it isJari Aalto
Signed-off-by: Jari Aalto <> Signed-off-by: Junio C Hamano <>
2007-03-30Merge branch 'maint'Junio C Hamano
* maint: git-upload-pack: make sure we close unused pipe ends Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES. Documentation/git-svnimport.txt: fix typo.
2007-03-29Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.Gerrit Pape
Please see In git-rev-parse(1), there is an example commit tree, which is used twice. The explanation for this tree is very clear: B and C are commit *parents* to A. However, when the tree is reused as an example in the SPECIFYING RANGES, the manpage author screws up and uses A as a commit *parent* to B and C! I.e., he inverts the tree. And the fact that for this example you need to read the tree backwards is not explained anywhere (and it would be confusing even if it was). Signed-off-by: Gerrit Pape <> Signed-off-by: Junio C Hamano <>
2007-02-24object name: introduce ':/<oneline prefix>' notationJohannes Schindelin
To name a commit, you can now say $ git rev-parse ':/Initial revision of "git"' and it will return the hash of the youngest commit whose commit message (the oneline) begins with the given prefix. For future extension, a leading exclamation mark is treated specially: if you want to match a commit message starting with a '!', just repeat the exclamation mark. So, to match a commit which starts with '!Hello World', use $ git show ':/!!Hello World' Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>