summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
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-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-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-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>
2012-05-22drop length limitations on gecos-derived names and emailsLibravatar Jeff King2-8/+0
When we pull the user's name from the GECOS field of the passwd file (or generate an email address based on their username and hostname), we put the result into a static buffer. While it's extremely unlikely that anybody ever hit these limits (after all, in such a case their parents must have hated them), we still had to deal with the error cases in our code. Converting these static buffers to strbufs lets us simplify the code and drop some error messages from the documentation that have confused some users. The conversion is mostly mechanical: replace string copies with strbuf equivalents, and access the strbuf.buf directly. There are a few exceptions: - copy_gecos and copy_email are the big winners in code reduction (since they no longer have to manage the string length manually) - git_ident_config wants to replace old versions of the default name (e.g., if we read the config multiple times), so it must reset+add to the strbuf instead of just adding Note that there is still one length limitation: the gethostname interface requires us to provide a static buffer, so we arbitrarily choose 1024 bytes for the hostname. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-20grep: support newline separated pattern listLibravatar René Scharfe1-1/+3
Currently, patterns that contain newline characters don't match anything when given to git grep. Regular grep(1) interprets patterns as lists of newline separated search strings instead. Implement this functionality by creating and inserting extra grep_pat structures for patterns consisting of multiple lines when appending to the pattern lists. For simplicity, all pattern strings are duplicated. The original pattern is truncated in place to make it contain only the first line. Requested-by: Torne (Richard Coles) <torne@google.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-18rev-parse doc: --git-dir does not always show a relative pathLibravatar Jon Seymour1-1/+2
The description was misleading because it lead the reader to believe that --git-dir would always show a relative path when, in fact, the actual behaviour does not guarantee this. Rather, it was intended that the advice be given that if a relative path is shown, then the path is relative to the current working directory and not some other directory (for example, the root of the working tree). Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-17git-svn: clarify the referent of dcommit's optional argumentLibravatar Jon Seymour1-20/+19
The documentation of the dcommit subcommand is reworded to clarify that the optional argument refers to a git branch, not an SVN branch. The discussion of the optional argument is put into its own paragraph as is the guidance about using 'dcommit' in preference to 'set-tree'. The section on REBASE vs. PULL/MERGE is reworded to incorporate the advice to prefer 'git rebase' previously in the description of 'dcommit'. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2012-05-16git-svn: support rebase --preserve-mergesLibravatar Avishay Lavie1-0/+2
When git svn rebase is performed after an unpushed merge, the rebase operation follows both parents and replays both the user's local commits and those from the merged branch. This is usually not the intended behavior. This patch adds support for the --preserve-merges/-p flag which allows for a better workflow by re-applying merge commits as merges. [ew: fixed a minor syntax error] Signed-off-by: Avishay Lavie <avishay.lavie@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-05-14Update draft release notes for 12th batchLibravatar Junio C Hamano1-24/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-30 21:34:02 +0000