summaryrefslogtreecommitdiff
path: root/Documentation/git-name-rev.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-05-02doc: keep first level section header in upper caseLibravatar Nguyễn Thái Ngọc Duy1-2/+2
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>
2017-01-23name-rev: add support to exclude refs by pattern matchLibravatar Jacob Keller1-0/+9
Extend git-name-rev to support excluding refs which match shell patterns using --exclude. These patterns can be used to limit the scope of refs by excluding any ref that matches one of the --exclude patterns. A ref will only be used for naming when it matches at least one --refs pattern but does not match any of the --exclude patterns. Thus, --exclude patterns are given precedence over --refs patterns. For example, suppose you wish to name a series of commits based on an official release tag of the form "v*" but excluding any pre-release tags which match "*rc*". You can use the following to do so: git name-rev --refs="v*" --exclude="*rc*" --all Add tests and update Documentation for this change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23name-rev: extend --refs to accept multiple patternsLibravatar Jacob Keller1-1/+3
Teach git name-rev to take multiple --refs stored as a string list of patterns. The list of patterns will be matched inclusively, and each ref only needs to match one pattern to be included. A ref will only be excluded if it does not match any of the given patterns. Additionally, if any of the patterns would allow abbreviation, then we will abbreviate the ref, even if another pattern is more strict and would not have allowed abbreviation on its own. Add tests and documentation for this change. The tests expected output is dynamically generated. This is in order to avoid hard-coding a commit object name in the test results (as the expected output is to simply leave the commit object unnamed). Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04use 'commit-ish' instead of 'committish'Libravatar Richard Hansen1-1/+1
Replace 'committish' in documentation and comments with 'commit-ish' to match gitglossary(7) and to be consistent with 'tree-ish'. The only remaining instances of 'committish' are: * variable, function, and macro names * "(also committish)" in the definition of commit-ish in gitglossary[7] Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12Merge branch 'rr/name-rev-stdin-doc'Libravatar Junio C Hamano1-2/+4
* rr/name-rev-stdin-doc: name-rev doc: rewrite --stdin paragraph
2013-07-07name-rev doc: rewrite --stdin paragraphLibravatar Ramkumar Ramachandra1-2/+4
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18name-rev: allow to specify a subpath for --refs optionLibravatar Namhyung Kim1-1/+2
When an user wants to filter specific ref using the --refs option, the pattern needs to match the full ref, e.g. --refs=refs/tags/v1.*. It'd be convenient to specify a subpath of ref pattern. For example, --refs=origin/* can find refs/remotes/origin/master by searching the pattern against its substrings in turn: refs/remotes/origin/master remotes/origin/master origin/master If it finds a match in a subpath, unambigous part of the ref path will be removed in the output. Signed-off-by: Namhyung Kim <namhyung.kim@lge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-9/+0
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-2/+2
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.
2008-08-30Fix example in git-name-rev documentationLibravatar Junio C Hamano1-1/+1
Since 59d3f54 (name-rev: avoid "^0" when unneeded, 2007-02-20), name-rev stopped showing an unnecessary "^0" to dereference a tag down to a commit. The patch should have made a matching update to the documentation, but we forgot. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-02Merge branch 'maint'Libravatar Junio C Hamano1-2/+1
* maint: git-name-rev: allow --name-only in combination with --stdin builtin-name-rev.c: split deeply nested part from the main function Conflicts: Documentation/git-name-rev.txt
2008-08-02git-name-rev: allow --name-only in combination with --stdinLibravatar Pieter de Bie1-2/+1
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-3/+3
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 <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-3/+3
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 <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-1/+1
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-08git-name-rev.txt: document --no-undefined and --alwaysLibravatar Stephan Beyer1-0/+7
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+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-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-2/+2
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>
2008-01-06Documentation: fix "gitlink::foobar[s]"Libravatar Junio C Hamano1-1/+1
They should be spelled with a single colon. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-24Documentation: Correct various misspellings and typos.Libravatar Brian Hetro1-1/+1
Fix minor typos throughout the documentation. Signed-off-by: Brian Hetro <whee@smaertness.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
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 <gitster@pobox.com>
2007-05-21Teach git-describe how to run name-revLibravatar Shawn O. Pearce1-0/+7
Often users want to know not which tagged version a commit came after, but which tagged version a commit is contained within. This latter task is the job of git-name-rev, but most users are looking to git-describe to do the job. Junio suggested we make `git describe --contains` run the correct tool, `git name-rev`, and that's exactly what we do here. The output of name-rev was adjusted slightly through the new --name-only option, allowing describe to execv into name-rev and maintain its current output format. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18Documentation: Added [verse] to SYNOPSIS where necessaryLibravatar Matthias Kestenholz1-0/+1
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17name-rev: introduce the --refs=<pattern> optionLibravatar Johannes Schindelin1-1/+5
Instead of (or, in addition to) --tags, to use only tags for naming, you can now use --refs=<pattern> to specify a shell glob pattern which the refs must match to be used for naming. Example: $ git name-rev --refs=*v1* 33db5f4d 33db5f4d tags/v1.0rc1^0~1593 Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-11typofix (git-name-rev documentation)Libravatar Alp Toker1-1/+1
Signed-off-by: Alp Toker <alp@atoker.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Fix more typos, primarily in the codeLibravatar Pavel Roskin1-1/+1
The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-07Some doc typo fixesLibravatar Francis Daly1-1/+1
All should be clear enough, except perhaps committish / commitish. I just kept the more-used one within the current docs. [jc: with rephrasing of check-ref-format description later discussed on the list] Signed-off-by: Francis Daly <francis@daoine.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05Several trivial documentation touch ups.Libravatar sean1-0/+1
Move incorrect asciidoc level 2 titles back to level 1. Show output of git-name-rev in man page example. Reword sentences that begin with a period (.) in asciidoc numbered lists to work around conversion to man page bug. Mention that git-repack now calls git-prune-packed when the -d option is passed to it. [imap] section headers in the config file example need to be contained in a literal block. imap.pass is the proper config file variable to use, not imap.password. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-09Remove trailing dot after short descriptionLibravatar Fredrik Kuivinen1-1/+1
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-26Add git-name-revLibravatar Johannes Schindelin1-0/+66
git-name-rev tries to find nice symbolic names for commits. It does so by walking the commits from the refs. When the symbolic name is ambiguous, the following heuristic is applied: Try to avoid too many ~'s, and if two ambiguous names have the same count of ~'s, take the one whose last number is smaller. With "--tags", the names are derived only from tags. With "--stdin", the stdin is parsed, and after every sha1 for which a name could be found, the name is appended. (Try "git log | git name-rev --stdin".) Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>