kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Thomas Rast	75d6e552a8	Documentation: @{-N} can refer to a commit The @{-N} syntax always referred to the N-th last thing checked out, which can be either a branch or a commit (for detached HEAD cases). However, the documentation only mentioned branches. Edit in a "/commit" in the appropriate places. Reported-by: Kevin <ikke@ikke.info> Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Felipe Contreras	9ba89f484e	Add new @ shortcut for HEAD Typing 'HEAD' is tedious, especially when we can use '@' instead. The reason for choosing '@' is that it follows naturally from the ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no operation, and when we don't have those, it makes sens to assume 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so let's make it invalid. Probably very few people, if any, used this name. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Richard Hansen	abdb54a1d2	revisions.txt: fix and clarify <rev>^{<type>} If possible, <rev> will be dereferenced even if it is not a tag type (e.g., commit dereferenced to a tree). Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Richard Hansen	75aa26d34c	peel_onion(): add support for <rev>^{tag} Complete the <rev>^{<type>} family of object descriptors by having <rev>^{tag} dereference <rev> until a tag object is found (or fail if unable). At first glance this may not seem very useful, as commits, trees, and blobs cannot be peeled to a tag, and a tag would just peel to itself. However, this can be used to ensure that <rev> names a tag object: $ git rev-parse --verify v1.8.4^{tag} `04f013dc38` $ git rev-parse --verify master^{tag} error: master^{tag}: expected tag type, but the object dereferences to tree type fatal: Needed a single revision Users can already ensure that <rev> is a tag object by checking the output of 'git cat-file -t <rev>', but: * users may expect <rev>^{tag} to exist given that <rev>^{commit}, <rev>^{tree}, and <rev>^{blob} all exist * this syntax is more convenient/natural in some circumstances Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Junio C Hamano	2c2b6646c2	Revert "Add new @ shortcut for HEAD" This reverts commit `cdfd94837b`, as it does not just apply to "@" (and forms with modifiers like @{u} applied to it), but also affects e.g. "refs/heads/@/foo", which it shouldn't. The basic idea of giving a short-hand might be good, and the topic can be retried later, but let's revert to avoid affecting existing use cases for now for the upcoming release.	12 years ago
Felipe Contreras	cdfd94837b	Add new @ shortcut for HEAD Typing 'HEAD' is tedious, especially when we can use '@' instead. The reason for choosing '@' is that it follows naturally from the ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no operation, and when we don't have those, it makes sens to assume 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so let's make it invalid. Probably very few people, if any, used this name. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Ramkumar Ramachandra	3a4dc48623	revisions.txt: clarify the .. and ... syntax In <rev1>..<rev2> and <rev1>...<rev2>, if either <rev1> or <rev2> is omitted, it defaults to 'HEAD'. Add this detail to the document. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Thomas Ackermann	d5fa1f1a69	The name of the hash function is "SHA-1", not "SHA1" Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Stefano Lattarini	e1c3bf496f	doc: various spelling fixes Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Junio C Hamano	a6a3f2cc07	peel_onion(): teach $foo^{object} peeler A string that names an object can be suffixed with ^{type} peeler to say "I have this object name; peel it until you get this type. If you cannot do so, it is an error". v1.8.2^{commit} asks for a commit that is pointed at an annotated tag v1.8.2; v1.8.2^{tree} unwraps it further to the top-level tree object. A special suffix ^{} (i.e. no type specified) means "I do not care what it unwraps to; just peel annotated tag until you get something that is not a tag". When you have a random user-supplied string, you can turn it to a bare 40-hex object name, and cause it to error out if such an object does not exist, with: git rev-parse --verify "$userstring^{}" for most objects, but this does not yield the tag object name when $userstring refers to an annotated tag. Introduce a new suffix, ^{object}, that only makes sure the given name refers to an existing object. Then git rev-parse --verify "$userstring^{object}" becomes a way to make sure $userstring refers to an existing object. This is necessary because the plumbing "rev-parse --verify" is only about "make sure the argument is something we can feed to get_sha1() and turn it into a raw 20-byte object name SHA-1" and is not about "make sure that 20-byte object name SHA-1 refers to an object that exists in our object store". When the given $userstring is already a 40-hex, by definition "rev-parse --verify $userstring" can turn it into a raw 20-byte object name. With "$userstring^{object}", we can make sure that the 40-hex string names an object that exists in our object store before "--verify" kicks in. Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Kacper Kornet	47e329ef7c	rev-parse: clarify documentation of $name@{upstream} syntax "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>	12 years ago
Thomas Ackermann	2de9b71138	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>	12 years ago
Nguyễn Thái Ngọc Duy	1452bd64f1	branch -v: align even when branch names are in UTF-8 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>	13 years ago
Junio C Hamano	003c84f6d2	specifying ranges: we did not mean to make ".." an empty set 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>	13 years ago
Junio C Hamano	ca5ee2d1fb	Enumerate revision range specifiers in the documentation 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>	13 years ago
Max Horn	89ce391b8e	Make <refname> documentation more consistent. 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>	13 years ago
Junio C Hamano	70eb130768	Documentation: do not assume that n > 1 in <rev>~$n 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>	13 years ago
Michael J Gruber	b62c769730	revisions.txt: language improvements Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Michael J Gruber	61e508d973	revisions.txt: structure with a labelled list 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>	14 years ago
Michael J Gruber	83456b1352	revisions.txt: consistent use of quotes 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>	14 years ago
Jay Soffian	d7e5c0cbfb	Introduce CHERRY_PICK_HEAD 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>	14 years ago
Nguyễn Thái Ngọc Duy	32574b68c5	get_sha1: support $commit^{/regex} syntax 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>	14 years ago
Nguyễn Thái Ngọc Duy	979f792951	get_sha1: support relative path ":path" syntax 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>	14 years ago
Matthieu Moy	95ad6d2de1	update comment and documentation for :/foo syntax 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>	15 years ago
Michael J Gruber	5a8f311789	Documentation: split off rev doc into include file 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>	15 years ago

34 Commits (d1053246554d176173893a5283dc0c0fb563ed03)