summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2012-07-30Git 1.7.11.4Libravatar Junio C Hamano2-1/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30Merge branch 'jk/maint-commit-document-editmsg' into maintLibravatar Junio C Hamano1-0/+9
"$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log message user edits was not documented. * jk/maint-commit-document-editmsg: commit: document the temporary commit message file
2012-07-30Merge branch 'kk/maint-commit-tree' into maintLibravatar Junio C Hamano1-1/+1
"git commit-tree" learned a more natural "-p <parent> <tree>" order of arguments long time ago, but recently forgot it by mistake. * kk/maint-commit-tree: Revert "git-commit-tree(1): update synopsis" commit-tree: resurrect command line parsing updates
2012-07-30Merge branch 'pg/maint-1.7.9-am-where-is-patch' into maintLibravatar Junio C Hamano1-0/+3
When "git am" failed, old timers knew to check .git/rebase-apply/patch to see what went wrong, but we never told the users about it. * pg/maint-1.7.9-am-where-is-patch: am: indicate where a failed patch is to be found
2012-07-23commit: document the temporary commit message fileLibravatar Jeff King1-0/+9
We do not document COMMIT_EDITMSG at all, but users may want to know about it for two reasons: 1. They may want to tell their editor to configure itself for formatting a commit message. 2. If a commit is aborted by an error, the user may want to recover the commit message they typed. Let's put a note in git-commit(1). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Git 1.7.11.3Libravatar Junio C Hamano2-1/+55
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-17Revert "git-commit-tree(1): update synopsis"Libravatar Junio C Hamano1-1/+1
This reverts commit d28436736a078a429213003a9472e8caeb86c286, which was done without realizing that the updated command line argument order was lost by mistake.
2012-07-13am: indicate where a failed patch is to be foundLibravatar Paul Gortmaker1-0/+3
If "git am" fails to apply something, the end user may need to know where to find the patch that failed to apply, so that the user can do other things (e.g. trying "GNU patch" on it, running "diffstat" to see what it tried to change, etc.) The input to "am" may have contained more than one patch, or the message may have been MIME encoded, and knowing what the user fed to "am" does not help very much for this purpose. Also introduce advice.amworkdir configuration to allow people who learned where to look to squelch this message. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-11Git 1.7.11.2Libravatar Junio C Hamano2-1/+55
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-11Merge branch 'cn/cherry-pick-range-docs' into maintLibravatar Junio C Hamano2-1/+13
The documentation for "git cherry-pick A B..C" was misleading. * 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-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-21Git 1.7.11.1Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-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-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>
2012-05-23Merge branch 'js/rev-parse-doc-fix'Libravatar Junio C Hamano1-1/+2
By Jon Seymour * js/rev-parse-doc-fix: rev-parse doc: --git-dir does not always show a relative path
2012-05-22ident: report passwd errors with a more friendly messageLibravatar Jeff King2-10/+0
When getpwuid fails, we give a cute but cryptic message. While it makes sense if you know that getpwuid or identity functions are being called, this code is triggered behind the scenes by quite a few git commands these days (e.g., receive-pack on a remote server might use it for a reflog; the current message is hard to distinguish from an authentication error). Let's switch to something that gives a little more context. While we're at it, we can factor out all of the cut-and-pastes of the "you don't exist" message into a wrapper function. Rather than provide xgetpwuid, let's make it even more specific to just getting the passwd entry for the current uid. That's the only way we use getpwuid anyway, and it lets us make an even more specific error message. The current message also fails to mention errno. While the usual cause for getpwuid failing is that the user does not exist, mentioning errno makes it easier to diagnose these problems. Note that POSIX specifies that errno remain untouched if the passwd entry does not exist (but will be set on actual errors), whereas some systems will return ENOENT or similar for a missing entry. We handle both cases in our wrapper. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>