summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2016-02-03Merge branch 'mk/asciidoctor-bq-workaround'Libravatar Junio C Hamano1-10/+10
* mk/asciidoctor-bq-workaround: Documentation: remove unnecessary backslashes
2016-02-03Merge branch 'tg/ls-remote-symref'Libravatar Junio C Hamano1-2/+16
"ls-remote" learned an option to show which branch the remote repository advertises as its primary by pointing its HEAD at. * tg/ls-remote-symref: ls-remote: add support for showing symrefs ls-remote: use parse-options api ls-remote: fix synopsis ls-remote: document --refs option ls-remote: document --quiet option
2016-02-03Merge branch 'tb/ls-files-eol'Libravatar Junio C Hamano1-0/+22
"git ls-files" learned a new "--eol" option to help diagnose end-of-line problems. * tb/ls-files-eol: ls-files: add eol diagnostics
2016-02-01Getting closer to 2.7.1Libravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01Merge branch 'jk/list-tag-2.7-regression'Libravatar Junio C Hamano2-2/+6
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-01-28Fourth batch for 2.8.cycleLibravatar Junio C Hamano1-1/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28Merge branch 'tk/interpret-trailers-in-place'Libravatar Junio C Hamano1-1/+23
"interpret-trailers" has been taught to optionally update a file in place, instead of always writing the result to the standard output. * tk/interpret-trailers-in-place: interpret-trailers: add option for in-place editing trailer: allow to write to files other than stdout
2016-01-26Third batch for 2.8 cycleLibravatar Junio C Hamano1-0/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26Merge branch 'ak/format-patch-odir-config'Libravatar Junio C Hamano2-1/+9
"git format-patch" learned to notice format.outputDirectory configuration variable. This allows "-o <dir>" option to be omitted on the command line if you always use the same directory in your workflow. * ak/format-patch-odir-config: format-patch: introduce format.outputDirectory configuration
2016-01-26Merge branch 'js/pull-rebase-i'Libravatar Junio C Hamano2-1/+7
"git pull --rebase" has been extended to allow invoking "rebase -i". * js/pull-rebase-i: completion: add missing branch.*.rebase values remote: handle the config setting branch.*.rebase=interactive pull: allow interactive rebase with --rebase=interactive
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King2-2/+6
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.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>
2016-01-20Second batch for 2.8 cycleLibravatar Junio C Hamano1-2/+79
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-20Merge branch 'tg/grep-no-index-fallback'Libravatar Junio C Hamano2-0/+8
"git grep" by default does not fall back to its "--no-index" behaviour outside a directory under Git's control (otherwise the user may by mistake end up running a huge recursive search); with a new configuration (set in $HOME/.gitconfig--by definition this cannot be set in the config file per project), this safety can be disabled. * tg/grep-no-index-fallback: builtin/grep: add grep.fallbackToNoIndex config t7810: correct --no-index test
2016-01-20Merge branch 'ss/clone-depth-single-doc'Libravatar Junio C Hamano2-9/+9
Documentation for "git fetch --depth" has been updated for clarity. * ss/clone-depth-single-doc: docs: clarify that --depth for git-fetch works with newly initialized repos docs: say "commits" in the --depth option wording for git-clone docs: clarify that passing --depth to git-clone implies --single-branch
2016-01-20Merge branch 'nd/exclusion-regression-fix'Libravatar Junio C Hamano1-19/+4
The ignore mechanism saw a few regressions around untracked file listing and sparse checkout selection areas in 2.7.0; the change that is responsible for the regression has been reverted. * nd/exclusion-regression-fix: Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
2016-01-20Merge branch 'ew/for-each-ref-doc'Libravatar Junio C Hamano1-2/+7
* ew/for-each-ref-doc: for-each-ref: document `creatordate` and `creator` fields
2016-01-20Merge branch 'dw/signoff-doc'Libravatar Junio C Hamano5-1/+9
The documentation has been updated to hint the connection between the '--signoff' option and DCO. * dw/signoff-doc: Expand documentation describing --signoff
2016-01-20Merge branch 'ss/user-manual'Libravatar Junio C Hamano2-10/+36
Drop a few old "todo" items by deciding that the change one of them suggests is not such a good idea, and doing the change the other one suggested to do. * ss/user-manual: user-manual: add addition gitweb information user-manual: add section documenting shallow clones glossary: define the term shallow clone user-manual: remove temporary branch entry from todo list
2016-01-20Merge branch 'mh/notes-allow-reading-treeish'Libravatar Junio C Hamano1-4/+4
Some "git notes" operations, e.g. "git log --notes=<note>", should be able to read notes from any tree-ish that is shaped like a notes tree, but the notes infrastructure required that the argument must be a ref under refs/notes/. Loosen it to require a valid ref only when the operation would update the notes (in which case we must have a place to store the updated notes tree, iow, a ref). * mh/notes-allow-reading-treeish: notes: allow treeish expressions as notes ref
2016-01-19ls-remote: add support for showing symrefsLibravatar Thomas Gummerer1-1/+8
Sometimes it's useful to know the main branch of a git repository without actually downloading the repository. This can be done by looking at the symrefs stored in the remote repository. Currently git doesn't provide a simple way to show the symrefs stored on the remote repository, even though the information is available. Add a --symref command line argument to the ls-remote command, which shows the symrefs in the remote repository. While there, replace a literal tab in the format string with \t to make it more obvious to the reader. Suggested-by: pedro rijo <pedrorijo91@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19ls-remote: fix synopsisLibravatar Thomas Gummerer1-1/+1
git ls-remote takes an optional get-url argument, and specifying the repository is optional. Fix the synopsis in the documentation to reflect this. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19ls-remote: document --refs optionLibravatar Thomas Gummerer1-1/+4
The --refs option was originally introduced in 2718ff0 ("Improve git-peek-remote"). The ls-remote command was first documented in 972b6fe ("ls-remote: drop storing operation and add documentation."), but the --refs option was never documented. Fix this. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19ls-remote: document --quiet optionLibravatar Thomas Gummerer1-1/+5
cefb2a5e3 ("ls-remote: print URL when no repo is specified") added a quiet option to ls-remote, but didn't add it to the documentation. Add it. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-18ls-files: add eol diagnosticsLibravatar Torsten Bögershausen1-0/+22
When working in a cross-platform environment, a user may want to check if text files are stored normalized in the repository and if .gitattributes are set appropriately. Make it possible to let Git show the line endings in the index and in the working tree and the effective text/eol attributes. The end of line ("eolinfo") are shown like this: "-text" binary (or with bare CR) file "none" text file without any EOL "lf" text file with LF "crlf" text file with CRLF "mixed" text file with mixed line endings. The effective text/eol attribute is one of these: "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf" git ls-files --eol gives an output like this: i/none w/none attr/text=auto t/t5100/empty i/-text w/-text attr/-text t/test-binary-2.png i/lf w/lf attr/text eol=lf t/t5100/rfc2047-info-0007 i/lf w/crlf attr/text eol=crlf doit.bat i/mixed w/mixed attr/ locale/XX.po to show what eol convention is used in the data in the index ('i'), and in the working tree ('w'), and what attribute is in effect, for each path that is shown. Add test cases in t0027. Helped-By: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14interpret-trailers: add option for in-place editingLibravatar Tobias Klauser1-1/+23
Add a command line option --in-place to support in-place editing akin to sed -i. This allows to write commands like the following: git interpret-trailers --trailer "X: Y" a.txt > b.txt && mv b.txt a.txt in a more concise way: git interpret-trailers --trailer "X: Y" --in-place a.txt Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13pull: allow interactive rebase with --rebase=interactiveLibravatar Johannes Schindelin2-1/+7
A couple of years ago, I found the need to collaborate on topic branches that were rebased all the time, and I really needed to see what I was rebasing when pulling, so I introduced an interactively-rebasing pull. The way builtin pull works, this change also supports the value 'interactive' for the 'branch.<name>.rebase' config variable, which is a neat thing because users can now configure given branches for interactively-rebasing pulls without having to type out the complete `--rebase=interactive` option every time they pull. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13format-patch: introduce format.outputDirectory configurationLibravatar Alexander Kuleshov2-1/+9
We can pass -o/--output-directory to the format-patch command to store patches in some place other than the working directory. This patch introduces format.outputDirectory configuration option for same purpose. The case of usage of this configuration option can be convenience to not pass every time -o/--output-directory if an user has pattern to store all patches in the /patches directory for example. The format.outputDirectory has lower priority than command line option, so if user will set format.outputDirectory and pass the command line option, a result will be stored in a directory that passed to command line option. Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Stephen P. Smith <ischis2@cox.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12First batch for post 2.7 cycleLibravatar Junio C Hamano1-0/+44
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12Merge branch 'vl/grep-configurable-threads'Libravatar Junio C Hamano2-0/+13
"git grep" can now be configured (or told from the command line) how many threads to use when searching in the working tree files. * vl/grep-configurable-threads: grep: add --threads=<num> option and grep.threads configuration grep: slight refactoring to the code that disables threading grep: allow threading even on a single-core machine
2016-01-12Merge branch 'ea/blame-progress'Libravatar Junio C Hamano2-1/+9
"git blame" learned to produce the progress eye-candy when it takes too much time before emitting the first line of the result. * ea/blame-progress: blame: add support for --[no-]progress option
2016-01-12Merge branch 'sb/submodule-parallel-fetch'Libravatar Junio C Hamano1-0/+7
Add a framework to spawn a group of processes in parallel, and use it to run "git fetch --recurse-submodules" in parallel. Rerolled and this seems to be a lot cleaner. The merge of the earlier one to 'next' has been reverted. * sb/submodule-parallel-fetch: submodules: allow parallel fetching, add tests and documentation fetch_populated_submodules: use new parallel job processing run-command: add an asynchronous parallel child processor sigchain: add command to pop all common signals strbuf: add strbuf_read_once to read without blocking xread: poll on non blocking fds submodule.c: write "Fetching submodule <foo>" to stderr
2016-01-12Merge branch 'ps/push-delete-option'Libravatar Junio C Hamano1-1/+1
"branch --delete" has "branch -d" but "push --delete" does not. * ps/push-delete-option: push: add '-d' as shorthand for '--delete' push: add '--delete' flag to synopsis
2016-01-12notes: allow treeish expressions as notes refLibravatar Mike Hommey1-4/+4
init_notes() is the main point of entry to the notes API. It ensures that the input can be used as ref, because it needs a ref to update to store notes tree after modifying it. There however are many use cases where notes tree is only read, e.g. "git log --notes=...". Any notes-shaped treeish could be used for such purpose, but it is not allowed due to existing restriction. Allow treeish expressions to be used in the case the notes tree is going to be used without write "permissions". Add a flag to distinguish whether the notes tree is intended to be used read-only, or will be updated. With this change, operations that use notes read-only can be fed any notes-shaped tree-ish can be used, e.g. git log --notes=notes@{1}. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12builtin/grep: add grep.fallbackToNoIndex configLibravatar Thomas Gummerer2-0/+8
Currently when git grep is used outside of a git repository without the --no-index option git simply dies. For convenience, add a grep.fallbackToNoIndex configuration variable. If set to true, git grep behaves like git grep --no-index if it is run outside of a git repository. It defaults to false, preserving the current behavior. Helped-by: Jeff King <peff@peff.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08docs: clarify that --depth for git-fetch works with newly initialized reposLibravatar Sebastian Schuberth1-4/+5
The original wording sounded as if --depth could only be used to deepen or shorten the history of existing repos. However, that is not the case. In a workflow like $ git init $ git remote add origin https://github.com/git/git.git $ git fetch --depth=1 The newly initialized repo is properly created as a shallow repo. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08docs: say "commits" in the --depth option wording for git-cloneLibravatar Sebastian Schuberth1-1/+1
It is not wrong to talk about "revisions" here, but in this context revisions are always commits, and that is how we already name it in the git-fetch docs. So align the docs by always referring to "commits". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"Libravatar Nguyễn Thái Ngọc Duy1-19/+4
This reverts commit 57534ee77d22e725d971ee89c77dc6aad61c573f. The feature added in that commit requires that patterns behave the same way from anywhere. But some patterns can behave differently depending on current "working" directory. The conditions to catch and avoid these patterns are too loose. The untracked listing[1] and sparse-checkout selection[2] can become incorrect as a result. [1] http://article.gmane.org/gmane.comp.version-control.git/283520 [2] http://article.gmane.org/gmane.comp.version-control.git/283532 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-07docs: clarify that passing --depth to git-clone implies --single-branchLibravatar Sebastian Schuberth1-5/+4
It is confusing to document how --depth behaves as part of the --single-branch docs. Better move that part to the --depth docs, saying that it implies --single-branch by default. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05Expand documentation describing --signoffLibravatar David A. Wheeler5-1/+9
Modify various document (man page) files to explain in more detail what --signoff means. This was inspired by https://lwn.net/Articles/669976/ where paulj noted, "adding [the] '-s' argument to [a] git commit doesn't really mean you have even heard of the DCO...". Extending git's documentation will make it easier to argue that developers understood --signoff when they use it. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05for-each-ref: document `creatordate` and `creator` fieldsLibravatar Eric Wong1-2/+7
These were introduced back in 2006 at 3175aa1ec28c but never documented. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Git 2.7Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Sync with 2.6.5Libravatar Junio C Hamano2-1/+21
2016-01-04Git 2.6.5Libravatar Junio C Hamano2-1/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-30user-manual: add addition gitweb informationLibravatar Stephen P. Smith1-4/+11
Rework the section on gitweb to add information about the cgi script and the instaweb command. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-30user-manual: add section documenting shallow clonesLibravatar Stephen P. Smith1-3/+20
Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-29glossary: define the term shallow cloneLibravatar Stephen P. Smith1-0/+5
There are several places in the documentation that the term shallow clone is used. Defining the term enables its use elsewhere with a known definition. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28Git 2.7-rc3Libravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28user-manual: remove temporary branch entry from todo listLibravatar Stephen P. Smith1-3/+0
In the section on "How to check out a different version of a project" the "new" branch is used as a temporary branch. A detached HEAD was not used since it was a new feature introduced just a couple weeks prior. The section could be changed to use and explain a detached HEAD, except that would increase the learning curve early in the manual. Detached HEADs are discussed a couple sections later under "Examining an old version without creating a new branch". Let's declare that it is a bad idea to rewrite the example that uses a temporary branch to do the sightseeing on a detached HEAD. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-22Git 2.7-rc2Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>