summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2012-06-25Merge branch 'cn/cherry-pick-range-docs'Libravatar Junio C Hamano2-1/+13
The command line argument of "git cherry-pick maint master..next" is just an ordinary revision range, which is unintuitive and at least deserves documentation. * cn/cherry-pick-range-docs: git-cherry-pick.txt: clarify the use of revision range notation Documentation: --no-walk is no-op if range is specified
2012-06-25Merge branch 'rr/doc-commit'Libravatar Junio C Hamano1-0/+8
* rr/doc-commit: commit: document a couple of options
2012-06-25Merge branch 'jk/no-more-asciidoc7'Libravatar Junio C Hamano1-18/+0
We no longer use AsciiDoc7 syntax in our documentation and favor a more modern style. * jk/no-more-asciidoc7: docs: drop antique comment from Makefile docs: drop asciidoc7compatible flag
2012-06-22Merge branch 'maint'Libravatar Junio C Hamano2-2/+2
* maint: Documentation: Fix misspellings
2012-06-22Documentation: Fix misspellingsLibravatar Leila Muhtasib2-2/+2
Signed-off-by: Leila Muhtasib <muhtasib@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-21Sync with 1.7.11.1Libravatar Junio C Hamano2-1/+11
2012-06-21The first batch for 1.7.12Libravatar Junio C Hamano1-0/+55
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-21Git 1.7.11.1Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-21Merge branch 'jk/clone-local'Libravatar Junio C Hamano1-7/+12
"git clone --local $path" started its life as an experiment to optionally use link/copy when cloning a repository on the disk, but we didn't deprecate it after we made the option a no-op to always use the optimization. The command learns "--no-local" option to turn this off, as a more explicit alternative over use of file:// URL. * jk/clone-local: clone: allow --no-local to turn off local optimizations docs/clone: mention that --local may be ignored
2012-06-20docs: always define git-relative-html-prefix attributeLibravatar Jeff King1-0/+2
Commit fe77b41 introduced a new attribute to let the linkgit macro create cross-directory HTML references from the technical/ and howto/ subdirectories back to the main documentation. We define that attribute to "../" on the command-line when building inside those subdirectories, and otherwise leave it unset under the assumption that it would default to being blank. Instead, asciidoc omits the link entirely, leading to broken documentation. Fix this by defining git-relative-html-prefix to blank in asciidoc.conf (and an instance on the command-line, when present, will override it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19git-commit-tree(1): update synopsisLibravatar Junio C Hamano1-1/+1
Even with many new kinds of options, the command still takes the single <tree> as the first argument. Probably we would want to update the command to allow it to take <tree>-ish at the end for consistency. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19Documentation: spelling fixesLibravatar Miklos Vajna6-6/+6
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-17Git 1.7.11Libravatar Junio C Hamano2-9/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-17Sync with 1.7.10.5Libravatar Junio C Hamano2-1/+14
2012-06-17Git 1.7.10.5Libravatar Junio C Hamano2-1/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-15git-cherry-pick.txt: clarify the use of revision range notationLibravatar Carlos Martín Nieto1-1/+12
When given a set of commits, cherry-pick will apply the changes for all of them. Specifying a simple range will also work as expected. This can lead the user to think that git cherry-pick A B..C may apply A and then B..C, but that is not what happens. Instead the revs are given to a single invocation of rev-list, which will consider A and C as positive revs and B as a negative one. The commit A will not be used if it is an ancestor of B. Add a note about this and add an example with this particular syntax, which has shown up on the list a few times. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-15Documentation: --no-walk is no-op if range is specifiedLibravatar Carlos Martín Nieto1-0/+1
The existing description can be misleading and cause the reader to think that --no-walk will do something if they specify a range in the command line instead of a set of revs. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-12Git 1.7.11-rc3Libravatar Junio C Hamano1-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-12Merge branch 'mm/api-credentials-doc'Libravatar Junio C Hamano1-1/+4
* mm/api-credentials-doc: api-credential.txt: document that helpers field is filled-in automatically
2012-06-12api-credential.txt: document that helpers field is filled-in automaticallyLibravatar Matthieu Moy1-1/+4
It was unclear whether the field was to be specified by the user of the API. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-08Merge branch 'mm/api-credentials-doc'Libravatar Junio C Hamano5-6/+8
Finishing touches... * mm/api-credentials-doc: docs: fix cross-directory linkgit references
2012-06-08docs: fix cross-directory linkgit referencesLibravatar Jeff King5-6/+8
Most of our documentation is in a single directory, so using linkgit:git-config[1] just generates a relative link in the same directory. However, this is not the case with the API documentation in technical/*, which need to refer to git-config from the parent directory. We can fix this by passing a special prefix attribute when building in a subdirectory, and respecting that prefix in our linkgit definitions. We only have to modify the html linkgit definition. For manpages, we can ignore this for two reasons: 1. we do not generate actual links to the file in manpages, but instead just give the name and section of the linked manpage 2. we do not currently build manpages for subdirectories, only html Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-08commit: document a couple of optionsLibravatar Ramkumar Ramachandra1-0/+8
Document git commit '--branch' and '--no-post-rewrite'. Mention that '-z' can also be spelt as '--null'. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-07Git 1.7.11-rc2Libravatar Junio C Hamano1-11/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-07Merge branch 'mm/api-credentials-doc'Libravatar Junio C Hamano3-7/+60
* mm/api-credentials-doc: api-credentials.txt: add "see also" section api-credentials.txt: mention credential.helper explicitly api-credentials.txt: show the big picture first doc: fix xref link from api docs to manual pages
2012-06-04api-credentials.txt: add "see also" sectionLibravatar Matthieu Moy1-0/+7
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-04api-credentials.txt: mention credential.helper explicitlyLibravatar Matthieu Moy1-2/+4
The name of the configuration variable was mentioned only at the very end of the explanation, in a place specific to a specific rule, hence it was not very clear what the specification was about. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-04api-credentials.txt: show the big picture firstLibravatar Matthieu Moy1-3/+47
The API documentation targets two kinds of developers: those using the C API, and those writing remote-helpers. The document was not clear about which part was useful to which category, and for example, the C API could be mistakenly thought as an API for writting remote helpers. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-04doc: fix xref link from api docs to manual pagesLibravatar Junio C Hamano2-2/+2
They are one-level above, so refer them as linkgit:../git-foo[n] with "../" Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03Git 1.7.11-rc1Libravatar Junio C Hamano1-6/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03Sync with 1.7.10.4Libravatar Junio C Hamano2-1/+6
* maint: Git 1.7.10.4
2012-06-03Git 1.7.10.4Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01Update draft release notes to 1.7.11Libravatar Junio C Hamano1-18/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01Sync with maintLibravatar Junio C Hamano2-1/+27
2012-06-01Start preparing for 1.7.10.4Libravatar Junio C Hamano2-1/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01Merge branch 'rs/maint-grep-F' into maintLibravatar Junio C Hamano1-1/+3
"git grep -e '$pattern'", unlike the case where the patterns are read from a file, did not treat individual lines in the given pattern argument as separate regular expressions as it should. By René Scharfe * rs/maint-grep-F: grep: stop leaking line strings with -f grep: support newline separated pattern list grep: factor out do_append_grep_pat() grep: factor out create_grep_pat()
2012-05-30clone: allow --no-local to turn off local optimizationsLibravatar Jeff King1-1/+3
This is basically the same as using "file://", but is a little less subtle for the end user. It also allows relative paths to be specified. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-30docs/clone: mention that --local may be ignoredLibravatar Jeff King1-7/+10
The --local flag is not "treat this like a local repository", but rather "if we are local, turn on optimizations". Therefore it does nothing in the case of: git clone --local file:///path/to/repo Let's make that more clear in the documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-30docs: drop antique comment from MakefileLibravatar Jeff King1-9/+0
This comment warns about a bug in asciidoc 6, and points to a patch from 2005. Since we don't even support versions of asciidoc that old, we can safely get rid of the warning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-30docs: drop asciidoc7compatible flagLibravatar Jeff King1-9/+0
When we made the switch to supporting asciidoc 8 in 4c7100a (Documentation: adjust to AsciiDoc 8, 2007-06-14), we were able to leave most of the documentation intact by defining asciidoc7compatible. Since commit 6cf378f (docs: stop using asciidoc no-inline-literal, 2012-04-26), we don't support versions of asciidoc older than 8.4.1, which is when inline literals were introduced. Therefore there is not much point in keeping our documentation compatible with asciidoc 7. So we are now free to drop the asciidoc7compatible flag and update the documentation itself to assume asciidoc8. Fortunately, doing the latter is very easy; we weren't using any of the constructs impacted by asciidoc7compatible, so there are no changes to make. The reason is somewhat subtle. The asciidoc7compatible affects only super/sub-scripts ("^" and "~") and index terms. We don't use the latter at all. Nor we do we use the former, but we did have to protect them from accidental expansion in constructs like "rev^1". However, all of our uses of "~" and "^" are either in code blocks (which are rendered literally), or inside backticks. Prior to 6cf378f, backticks were not inline literals, and needed proper quoting. But post-6cf378f, we don't have to worry whether we are using the old or new rules, as those characters are not interpreted at all in either case. I verified that the result of "make install-html install-man" is identical before and after this patch on asciidoc 8.6.7. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-29Merge branch 'jk/ident-gecos-strbuf'Libravatar Junio C Hamano2-18/+0
Fixes quite a lot of brokenness when ident information needs to be taken from the system and cleans up the code. By Jeff King * jk/ident-gecos-strbuf: (22 commits) format-patch: do not use bogus email addresses in message ids ident: reject bogus email addresses with IDENT_STRICT ident: rename IDENT_ERROR_ON_NO_NAME to IDENT_STRICT format-patch: use GIT_COMMITTER_EMAIL in message ids ident: let callers omit name with fmt_indent ident: refactor NO_DATE flag in fmt_ident ident: reword empty ident error message format-patch: refactor get_patch_filename ident: trim whitespace from default name/email ident: use a dynamic strbuf in fmt_ident ident: use full dns names to generate email addresses ident: report passwd errors with a more friendly message drop length limitations on gecos-derived names and emails ident: don't write fallback username into git_default_name fmt_ident: drop IDENT_WARN_ON_NO_NAME code format-patch: use default email for generating message ids ident: trim trailing newline from /etc/mailname move git_default_* variables to ident.c move identity config parsing to ident.c fmt-merge-msg: don't use static buffer in record_person ...
2012-05-25Git 1.7.11-rc0Libravatar Junio C Hamano1-17/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25Merge branch 'rs/maint-grep-F'Libravatar Junio C Hamano1-1/+3
"git grep -e '$pattern'", unlike the case where the patterns are read from a file, did not treat individual lines in the given pattern argument as separate regular expressions as it should.
2012-05-25Sync with 1.7.10.3Libravatar Junio C Hamano2-7/+16
2012-05-25Git 1.7.10.3Libravatar Junio C Hamano1-4/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25config doc: remove confusion about relative GIT_DIR from FILES sectionLibravatar Jonathan Nieder1-3/+1
From the FILES section of the git-config(1) manual: $GIT_DIR/config:: Repository specific configuration file. (The filename is of course relative to the repository root, not the working directory.) That's confusing because $GIT_DIR really is relative to the working directory. $ GIT_DIR=.git GIT_EDITOR='pwd; echo editing' $ export GIT_DIR GIT_EDITOR $ git config --edit --local /home/jrn/src/git/Documentation editing .git/config It turns out that the comment is a remnant from older days when the heading said ".git/config" (which is indeed relative to the top of the worktree). It was only when the heading was changed to refer more precisely to <git dir>/config (see v1.5.3.2~18, AsciiDoc tweak to avoid leading dot, 2007-09-14) that the parenthesis stopped making sense. Remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-24Sync with maintLibravatar Junio C Hamano1-0/+6
By Jeff King (1) and Junio C Hamano (1) * maint: Update draft release notes to 1.7.10.3 osxkeychain: pull make config from top-level directory
2012-05-24Update draft release notes to 1.7.10.3Libravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-24Merge branch 'jk/maint-status-porcelain-z-b' into maintLibravatar Junio C Hamano1-1/+1
"git status --porcelain" ignored "--branch" option by mistake. The output for "git status --branch -z" was also incorrect and did not terminate the record for the current branch name with NUL as asked. By Jeff King * jk/maint-status-porcelain-z-b: status: respect "-b" for porcelain format status: fix null termination with "-b" status: refactor null_termination option commit: refactor option parsing
2012-05-23Update draft release notes to 1.7.11Libravatar Junio C Hamano1-0/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-25 15:39:21 +0000