summaryrefslogtreecommitdiff
path: root/Documentation/revisions.txt
AgeCommit message (Collapse)AuthorFilesLines
2020-04-21docs: fix minor glitch in illustrationLibravatar Michael F. Schönitzer1-1/+1
In the example by Jon Loeliger the selector 'A^2' was duplicated. This might confuse readers. Signed-off-by: Michael F. Schönitzer <michael@schoenitzer.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-1/+1
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-05-13Merge branch 'dl/rev-tilde-doc-clarify'Libravatar Junio C Hamano1-15/+14
Docfix. * dl/rev-tilde-doc-clarify: revisions.txt: remove ambibuity between <rev>:<path> and :<path> revisions.txt: mention <rev>~ form revisions.txt: mark optional rev arguments with [] revisions.txt: change "rev" to "<rev>"
2019-05-08revisions.txt: remove ambibuity between <rev>:<path> and :<path>Libravatar Andreas Heiduk1-5/+2
The revision ':README' is mentioned as an example for '<rev>:<path>' but the explanation forwards to the ':<n>:<path>' syntax. At the same time ':<n>:<path>' did not mark the '<n>:' as optional. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08revisions.txt: mention <rev>~ formLibravatar Denton Liu1-1/+3
In revisions.txt, the '<rev>^' form is mentioned but the '<rev>~' form is missing. Although both forms are essentially equivalent (they each get the first parent of the specified revision), we should mention the latter for completeness. Make this change. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08revisions.txt: mark optional rev arguments with []Libravatar Denton Liu1-5/+5
In revisions.txt, an optional rev argument was not distinguised. Instead, a user had to continue and read the description in order to learn that the argument was optional. Since the [] notation for an optional argument is common-knowledge in the Git documentation, mark optional arguments with [] so that it's more obvious for the reader. Helped-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08revisions.txt: change "rev" to "<rev>"Libravatar Denton Liu1-4/+4
In revisions.txt, there were some instances of a rev argument being written as "rev". However, since they didn't mean the string literal, write "<rev>", instead. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02doc: promote "git switch"Libravatar Nguyễn Thái Ngọc Duy1-1/+1
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-13doc: format pathnames and URLs as monospace.Libravatar Corentin BOMPARD1-2/+2
Applying CodingGuidelines about monospace on pathnames and URLs. See Documentation/CodingGuidelines.txt for more information. Signed-off-by: Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr> Signed-off-by: Nathan BERBEZIER <nathan.berbezier@etu.univ-lyon1.fr> Signed-off-by: Pablo CHABANNE <pablo.chabanne@etu.univ-lyon1.fr> Signed-off-by: Matthieu MOY <matthieu.moy@univ-lyon1.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-24Merge branch 'wc/find-commit-with-pattern-on-detached-head'Libravatar Junio C Hamano1-1/+2
"git rev-parse ':/substring'" did not consider the history leading only to HEAD when looking for a commit with the given substring, when the HEAD is detached. This has been fixed. * wc/find-commit-with-pattern-on-detached-head: sha1-name.c: for ":/", find detached HEAD commits
2018-07-12sha1-name.c: for ":/", find detached HEAD commitsLibravatar William Chargin1-1/+2
This patch broadens the set of commits matched by ":/<pattern>" to include commits reachable from HEAD but not any named ref. This avoids surprising behavior when working with a detached HEAD and trying to refer to a commit that was recently created and only exists within the detached state. If multiple worktrees exist, only the current worktree's HEAD is considered reachable. This is consistent with the existing behavior for other per-worktree refs: e.g., bisect refs are considered reachable, but only within the relevant worktree. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-23Merge branch 'bc/asciidoctor-tab-width'Libravatar Junio C Hamano1-0/+2
Asciidoctor gives a reasonable imitation for AsciiDoc, but does not render illustration in a literal block correctly when indented with HT by default. The problem is fixed by forcing 8-space tabs. * bc/asciidoctor-tab-width: Documentation: render revisions correctly under Asciidoctor Documentation: use 8-space tabs with Asciidoctor
2018-05-07Documentation: render revisions correctly under AsciidoctorLibravatar brian m. carlson1-0/+2
When creating a literal block from an indented block without any sort of delimiters, Asciidoctor strips off all leading whitespace, resulting in a misrendered chart. Use an explicit literal block to indicate to Asciidoctor that we want to keep the leading whitespace. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06doc: add note about shell quoting to revision.txtLibravatar Andreas Heiduk1-0/+6
Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Reviewed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-04Documentation: revisions: fix typo: "three dot" ---> "three-dot" (in line ↵Libravatar Ann T Ropea1-1/+1
with "two-dot"). Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-19Merge branch 'vn/revision-shorthand-for-side-branch-log'Libravatar Junio C Hamano1-2/+2
Doc cleanup. * vn/revision-shorthand-for-side-branch-log: doc/revisions: remove brackets from rev^-n shorthand
2017-04-16doc/revisions: remove brackets from rev^-n shorthandLibravatar Kyle Meyer1-2/+2
Given that other instances of "{...}" in the revision documentation represent literal characters of revision specifications, describing the rev^-n shorthand as "<rev>^-{<n>}" incorrectly suggests that something like "master^-{1}" is an acceptable form. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27rev-parse: match @{upstream}, @{u} and @{push} case-insensitivelyLibravatar Ævar Arnfjörð Bjarmason1-1/+5
Change the revision parsing logic to match @{upstream}, @{u} & @{push} case-insensitively. Before this change supplying anything except the lower-case forms emits an "unknown revision or path not in the working tree" error. This change makes upper-case & mixed-case versions equivalent to the lower-case versions. The use-case for this is being able to hold the shift key down while typing @{u} on certain keyboard layouts, which makes the sequence easier to type, and reduces cases where git throws an error at the user where it could do what he means instead. These suffixes now join various other suffixes & special syntax documented in gitrevisions(7) that matches case-insensitively. A table showing the status of the various forms documented there before & after this patch is shown below. The key for the table is: - CI = Case Insensitive - CIP = Case Insensitive Possible (without ambiguities) - AG = Accepts Garbage (.e.g. @{./.4.minutes./.}) Before this change: |----------------+-----+------+-----| | What? | CI? | CIP? | AG? | |----------------+-----+------+-----| | @{<date>} | Y | Y | Y | | @{upstream} | N | Y | N | | @{push} | N | Y | N | |----------------+-----+------+-----| After it: |----------------+-----+------+-----| | What? | CI? | CIP? | AG? | |----------------+-----+------+-----| | @{<date>} | Y | Y | Y | | @{upstream} | Y | Y | N | | @{push} | Y | Y | N | |----------------+-----+------+-----| The ^{<type>} suffix is not made case-insensitive, because other places that take <type> like "cat-file -t <type>" do want them case sensitively (after all we never declared that type names are case insensitive). Allowing case-insensitive typename only with this syntax will make the resulting Git as a whole inconsistent. This change was independently authored to scratch a longtime itch, but when I was about to submit it I discovered that a similar patch had been submitted unsuccessfully before by Conrad Irwin in August 2011 as "rev-parse: Allow @{U} as a synonym for @{u}" (<1313287071-7851-1-git-send-email-conrad.irwin@gmail.com>). The tests for this patch are more exhaustive than in the 2011 submission. The starting point for them was to first change the code to only support upper-case versions of the existing words, seeing what broke, and amending the breaking tests to check upper case & mixed case as appropriate, and where not redundant to other similar tests. The implementation itself is equivalent. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-27revision: new rev^-n shorthand for rev^n..revLibravatar Vegard Nossum1-2/+15
"git log rev^..rev" is commonly used to show all work done on and merged from a side branch. This patch introduces a shorthand "rev^-" for this and additionally allows "rev^-$n" to mean "reachable from rev, excluding what is reachable from the nth parent of rev". For example, for a two-parent merge, you can use rev^-2 to get the set of commits which were made to the main branch while the topic branch was prepared. Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-19Merge branch 'po/range-doc' into maintLibravatar Junio C Hamano1-44/+81
Clarify various ways to specify the "revision ranges" in the documentation. * po/range-doc: doc: revisions: sort examples and fix alignment of the unchanged doc: revisions: show revision expansion in examples doc: revisions - clarify reachability examples doc: revisions - define `reachable` doc: gitrevisions - clarify 'latter case' is revision walk doc: gitrevisions - use 'reachable' in page description doc: revisions: single vs multi-parent notation comparison doc: revisions: extra clarification of <rev>^! notation effects doc: revisions: give headings for the two and three dot notations doc: show the actual left, right, and boundary marks doc: revisions - name the left and right sides doc: use 'symmetric difference' consistently
2016-08-13doc: revisions: sort examples and fix alignment of the unchangedLibravatar Philip Oakley1-6/+6
The previous commit adjusted the column alignment for revision examples which show expansion. Fix the unchanged examples and sort those that show expansions to the end of the list. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-13doc: revisions: show revision expansion in examplesLibravatar Philip Oakley1-6/+17
The revisions examples show the revison arguments and the selected commits, but do not show the intermediate step of the expansion of the special 'range' notations. Extend the examples, including an all-parents multi-parent merge commit example. Sort the examples and fix the alignment for those unaffected in the next commit. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-13doc: revisions - clarify reachability examplesLibravatar Philip Oakley1-5/+6
For the r1..r2 case, the exclusion of r1, rather than inclusion of r2, would be the unexpected case in natural language for a simple linear development, i.e. start..end excludes start. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-13doc: revisions - define `reachable`Libravatar Philip Oakley1-4/+10
Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-13doc: revisions: single vs multi-parent notation comparisonLibravatar Philip Oakley1-0/+4
Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-13doc: revisions: extra clarification of <rev>^! notation effectsLibravatar Philip Oakley1-1/+2
Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12doc: revisions: give headings for the two and three dot notationsLibravatar Philip Oakley1-22/+36
While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). We do not quote the notation within the headings as the asciidoc -> docbook -> groff man viewer toolchain, particularly the docbook-groff step, does not cope with two font changes, failing to return the heading font to bold after the quotation of the notation. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-20doc: revisions - name the left and right sidesLibravatar Philip Oakley1-1/+1
The terms left and right side originate from the symmetric difference. Name them there. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset HEAD and variants as literalLibravatar Matthieu Moy1-12/+12
This is an application of the newly added CodingGuidelines to HEAD and variants like FETCH_HEAD. It was obtained with: perl -pi -e "s/'([A-Z_]*HEAD)'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-1/+1
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10Merge branch 'wp/sha1-name-negative-match'Libravatar Junio C Hamano1-5/+6
A new "<branch>^{/!-<pattern>}" notation can be used to name a commit that is reachable from <branch> that does not match the given <pattern>. * wp/sha1-name-negative-match: object name: introduce '^{/!-<negative pattern>}' notation test for '!' handling in rev-parse's named commits
2016-02-01object name: introduce '^{/!-<negative pattern>}' notationLibravatar Will Palmer1-5/+6
To name a commit, you can now use the :/!-<negative pattern> regex style, and consequentially, say $ git rev-parse HEAD^{/!-foo} and it will return the hash of the first commit reachable from HEAD, whose commit message does not contain "foo". This is the opposite of the existing <rev>^{/<pattern>} syntax. The specific use-case this is intended for is to perform an operation, excluding the most-recent commits containing a particular marker. For example, if you tend to make "work in progress" commits, with messages beginning with "WIP", you work, then it could be useful to diff against "the most recent commit which was not a WIP commit". That sort of thing now possible, via commands such as: $ git diff @^{/!-^WIP} The leader '/!-', rather than simply '/!', to denote a negative match, is chosen to leave room for additional modifiers in the future. Signed-off-by: Will Palmer <wmpalmer@gmail.com> Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-20Documentation: remove unnecessary backslashesLibravatar Matthew Kraai1-10/+10
asciidoctor does not remove backslashes used to escape curly brackets from the HTML output if the contents of the curly brackets are empty or contain at least a <, -, or space. asciidoc does not require the backslashes in these cases, so just remove them. Signed-off-by: Matthew Kraai <matt.kraai@abbott.com> Reported-by: Philip Oakley <philipoakley@iee.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22sha1_name: implement @{push} shorthandLibravatar Jeff King1-0/+25
In a triangular workflow, each branch may have two distinct points of interest: the @{upstream} that you normally pull from, and the destination that you normally push to. There isn't a shorthand for the latter, but it's useful to have. For instance, you may want to know which commits you haven't pushed yet: git log @{push}.. Or as a more complicated example, imagine that you normally pull changes from origin/master (which you set as your @{upstream}), and push changes to your own personal fork (e.g., as myfork/topic). You may push to your fork from multiple machines, requiring you to integrate the changes from the push destination, rather than upstream. With this patch, you can just do: git rebase @{push} rather than typing out the full name. The heavy lifting is all done by branch_get_push; here we just wire it up to the "@{push}" syntax. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-13Documentation: mention config sources for @{upstream}Libravatar W. Trevor King1-1/+3
The earlier documentation made vague references to "is set to build on". Flesh that out with references to the config settings, so folks can use git-config(1) to get more detail on what @{upstream} means. For example, @{upstream} does not care about remote.pushdefault or branch.<name>.pushremote. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-21Documentation: @{-N} can refer to a commitLibravatar Thomas Rast1-1/+1
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>
2013-09-20Merge branch 'fc/at-head'Libravatar Junio C Hamano1-0/+3
Instead of typing four capital letters "HEAD", you can say "@" now, e.g. "git log @". * fc/at-head: Add new @ shortcut for HEAD sha1-name: pass len argument to interpret_branch_name()
2013-09-20Merge branch 'rh/peeling-tag-to-tag'Libravatar Junio C Hamano1-0/+3
Make "foo^{tag}" to peel a tag to itself, i.e. no-op., and fail if "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" would be a more convenient way to say "test $(git cat-file -t v1.0) = tag". * rh/peeling-tag-to-tag: peel_onion: do not assume length of x_type globals peel_onion(): add support for <rev>^{tag}
2013-09-12Add new @ shortcut for HEADLibravatar Felipe Contreras1-0/+3
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>
2013-09-04revisions.txt: fix and clarify <rev>^{<type>}Libravatar Richard Hansen1-4/+8
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>
2013-09-03peel_onion(): add support for <rev>^{tag}Libravatar Richard Hansen1-0/+3
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} 04f013dc38d7512eadb915eba22efc414f18b869 $ 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>
2013-08-14Revert "Add new @ shortcut for HEAD"Libravatar Junio C Hamano1-3/+0
This reverts commit cdfd94837b27c220f70f032b596ea993d195488f, 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.
2013-05-08Add new @ shortcut for HEADLibravatar Felipe Contreras1-0/+3
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>
2013-04-26Merge branch 'rr/shortlog-doc'Libravatar Junio C Hamano1-2/+4
Update documentation for "log" and "shortlog". * rr/shortlog-doc: builtin/shortlog.c: make usage string consistent with log builtin/log.c: make usage string consistent with doc git-shortlog.txt: make SYNOPSIS match log, update OPTIONS git-log.txt: rewrite note on why "--" may be required git-log.txt: generalize <since>..<until> git-log.txt: order OPTIONS properly; move <since>..<until> revisions.txt: clarify the .. and ... syntax git-shortlog.txt: remove (-h|--help) from OPTIONS
2013-04-21revisions.txt: clarify the .. and ... syntaxLibravatar Ramkumar Ramachandra1-2/+4
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>
2013-04-21Merge branch 'ta/glossary'Libravatar Junio C Hamano1-2/+2
* ta/glossary: glossary: improve definitions of refspec and pathspec The name of the hash function is "SHA-1", not "SHA1" glossary: improve description of SHA-1 related topics glossary: remove outdated/misleading/irrelevant entries
2013-04-15The name of the hash function is "SHA-1", not "SHA1"Libravatar Thomas Ackermann1-2/+2
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>
2013-04-12Sync with 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Correct common spelling mistakes in comments and tests kwset: fix spelling in comments precompose-utf8: fix spelling of "want" in error message compat/nedmalloc: fix spelling in comments compat/regex: fix spelling and grammar in comments obstack: fix spelling of similar contrib/subtree: fix spelling of accidentally git-remote-mediawiki: spelling fixes doc: various spelling fixes fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format i18n: make the translation of -u advice in one go
2013-04-12doc: various spelling fixesLibravatar Stefano Lattarini1-1/+1
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>
2013-04-03Merge branch 'jc/sha1-name-object-peeler'Libravatar Junio C Hamano1-0/+5
There was no good way to ask "I have a random string that came from outside world. I want to turn it into a 40-hex object name while making sure such an object exists". A new peeling suffix ^{object} can be used for that purpose, together with "rev-parse --verify". * jc/sha1-name-object-peeler: peel_onion(): teach $foo^{object} peeler peel_onion: disambiguate to favor tree-ish when we know we want a tree-ish