summaryrefslogtreecommitdiff
path: root/Documentation/revisions.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-03-17Merge branch 'maint'Libravatar Junio C Hamano1-4/+4
* maint: rev-parse: clarify documentation of $name@{upstream} syntax sha1_name: pass object name length to diagnose_invalid_sha1_path() Makefile: keep LIB_H entries together and sorted
2013-03-17rev-parse: clarify documentation of $name@{upstream} syntaxLibravatar Kacper Kornet1-4/+4
"git rev-parse" interprets string in string@{upstream} as a name of a branch not a ref. For example, refs/heads/master@{upstream} looks for an upstream branch that is merged by git-pull to ref refs/heads/refs/heads/master not to refs/heads/master. However the documentation could mislead a user to believe that the string is interpreted as ref. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-07Merge branch 'nd/branch-v-alignment'Libravatar Junio C Hamano1-0/+2
Output from "git branch -v" contains "(no branch)" that could be localized, but the code to align it along with the names of branches were counting in bytes, not in display columns. * nd/branch-v-alignment: branch -v: align even when branch names are in UTF-8
2012-08-27branch -v: align even when branch names are in UTF-8Libravatar Nguyễn Thái Ngọc Duy1-0/+2
Branch names are usually in ASCII so they are not the problem. The problem most likely comes from "(no branch)" translation, which is in UTF-8 and makes display-width calculation just wrong. Clarify this by renaming the field "len" in struct ref_item to "width", as it stores the display-width and is used to compute the width of the screen needed to show the names of all the branches, and compute the display width using utf8_strwidth(), not byte-length with strlen(). Update document to mention the fact that we may want ref names in UTF-8. Encodings that produce invalid UTF-8 are safe as utf8_strwidth() falls back to strlen(). The ones that incidentally produce valid UTF-8 sequences will cause misalignment. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-23specifying ranges: we did not mean to make ".." an empty setLibravatar Junio C Hamano1-0/+7
Either end of revision range operator can be omitted to default to HEAD, as in "origin.." (what did I do since I forked) or "..origin" (what did they do since I forked). But the current parser interprets ".." as an empty range "HEAD..HEAD", and worse yet, because ".." does exist on the filesystem, we get this annoying output: $ cd Documentation/howto $ git log .. ;# give me recent commits that touch Documentation/ area. fatal: ambiguous argument '..': both revision and filename Use '--' to separate filenames from revisions Surely we could say "git log ../" or even "git log -- .." to disambiguate, but we shouldn't have to. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-24Enumerate revision range specifiers in the documentationLibravatar Junio C Hamano1-0/+31
It was a bit hard to learn how <rev>^@, <rev>^! and various other forms of range specifiers are used, because they were discussed mostly in the prose part of the documentation, unlike various forms of extended SHA-1 expressions that are listed in an enumerated list. Also add a few more examples showing use of <rev>, <rev>..<rev> and <rev>^! forms, stolen from a patch by Max Horn. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-05Make <refname> documentation more consistent.Libravatar Max Horn1-6/+6
Formerly, the documentation for <refname> would occasionally say <name> instead of <refname>. Now it uniformly uses <refname>. Signed-off-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-02Documentation: do not assume that n > 1 in <rev>~$nLibravatar Junio C Hamano1-1/+1
We explained <rev>~<n> as <n>th generation grand-parent, but a reader got confused by the "grand-" part when <n> is 1. Reword it with "ancestor"; with the "generation" and "following only the first parents" around there, what we try to describe should be clear enough now. Noticed-by: Luke Diamand <luke@diamand.org> Helped-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04revisions.txt: language improvementsLibravatar Michael J Gruber1-35/+35
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01revisions.txt: structure with a labelled listLibravatar Michael J Gruber1-35/+51
Currently, the reader has to parse a textual description in order to find a specific syntax in the list. Restructure as a labelled list with systematic labels as well as concrete examples as a visual guide. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01revisions.txt: consistent use of quotesLibravatar Michael J Gruber1-52/+52
Our use of quotes is inconsistent everywhere and within some files. Before reworking the structure of revisions.txt, make the quotes consistent: `git command` 'some snippet or term' The former gets typeset as code, the latter with some form of emphasis. the man backend uses two types of emphasis. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21Introduce CHERRY_PICK_HEADLibravatar Jay Soffian1-1/+4
When a cherry-pick conflicts git advises: $ git commit -c <original commit id> to preserve the original commit message and authorship. Instead, let's record the original commit id in CHERRY_PICK_HEAD and advise: $ git commit -c CHERRY_PICK_HEAD A later patch teaches git to handle the '-c CHERRY_PICK_HEAD' part. Note that we record CHERRY_PICK_HEAD even in the case where there are no conflicts so that we may use it to communicate authorship to commit; this will then allow us to remove set_author_ident_env from revert.c. However, we do not record CHERRY_PICK_HEAD when --no-commit is used, as presumably the user intends to further edit the commit and possibly even cherry-pick additional commits on top. Tests and documentation contributed by Jonathan Nieder. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-21Merge branch 'nd/oneline-sha1-name-from-specific-ref'Libravatar Junio C Hamano1-0/+6
* nd/oneline-sha1-name-from-specific-ref: get_sha1: handle special case $commit^{/} get_sha1: support $commit^{/regex} syntax get_sha1_oneline: make callers prepare the commit list to traverse get_sha1_oneline: fix lifespan rule of temp_commit_buffer variable
2010-12-14get_sha1: support $commit^{/regex} syntaxLibravatar Nguyễn Thái Ngọc Duy1-0/+6
This works like ":/regex" syntax that finds a recently created commit starting from all refs, but limits the discovery to those reachable from the named commit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-07get_sha1: support relative path ":path" syntaxLibravatar Nguyễn Thái Ngọc Duy1-0/+4
Currently :path and ref:path can be used to refer to a specific object in index or ref respectively. "path" component is absolute path. This patch allows "path" to be written as "./path" or "../path", which is relative to user's original cwd. This does not work in commands for which startup_info is NULL (i.e. non-builtin ones, it seems none of them needs this anyway). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27update comment and documentation for :/foo syntaxLibravatar Matthieu Moy1-1/+3
The documentation in revisions.txt did not match the implementation, and the comment in sha1_name.c was incomplete. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05Documentation: split off rev doc into include fileLibravatar Michael J Gruber1-0/+199
Currently, the documentation for revisions and ranges sits in the git-rev-parse man page, i.e. a plumbing man page, along with the documentation of all rev-parse modes. Split off the revisions and ranges section into an included file to prepare for restructuring. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>