summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2021-07-26ref-filter: --format=%(raw) support --perlLibravatar ZheNing Hu1-2/+2
Because the perl language can handle binary data correctly, add the function perl_quote_buf_with_len(), which can specify the length of the data and prevent the data from being truncated at '\0' to help `--format="%(raw)"` support `--perl`. Reviewed-by: Jacob Keller <jacob.keller@gmail.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-26ref-filter: add %(raw) atomLibravatar ZheNing Hu1-0/+9
Add new formatting option `%(raw)`, which will print the raw object data without any changes. It will help further to migrate all cat-file formatting logic from cat-file to ref-filter. The raw data of blob, tree objects may contain '\0', but most of the logic in `ref-filter` depends on the output of the atom being text (specifically, no embedded NULs in it). E.g. `quote_formatting()` use `strbuf_addstr()` or `*._quote_buf()` add the data to the buffer. The raw data of a tree object is `100644 one\0...`, only the `100644 one` will be added to the buffer, which is incorrect. Therefore, we need to find a way to record the length of the atom_value's member `s`. Although strbuf can already record the string and its length, if we want to replace the type of atom_value's member `s` with strbuf, many places in ref-filter that are filled with dynamically allocated mermory in `v->s` are not easy to replace. At the same time, we need to check if `v->s == NULL` in populate_value(), and strbuf cannot easily distinguish NULL and empty strings, but c-style "const char *" can do it. So add a new member in `struct atom_value`: `s_size`, which can record raw object size, it can help us add raw object data to the buffer or compare two buffers which contain raw object data. Note that `--format=%(raw)` cannot be used with `--python`, `--shell`, `--tcl`, and `--perl` because if the binary raw data is passed to a variable in such languages, these may not support arbitrary binary data in their string variable type. Reviewed-by: Jacob Keller <jacob.keller@gmail.com> Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Hariom Verma <hariom18599@gmail.com> Helped-by: Bagas Sanjaya <bagasdotme@gmail.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Felipe Contreras <felipe.contreras@gmail.com> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Based-on-patch-by: Olga Telezhnaya <olyatelezhnaya@gmail.com> Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-14The second batchLibravatar Junio C Hamano1-2/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-14Merge branch 'fc/doc-build-cleanup'Libravatar Junio C Hamano1-48/+29
Preparatory build procedure clean-up for documentation. * fc/doc-build-cleanup: doc: avoid using rm directly doc: simplify Makefile using .DELETE_ON_ERROR doc: remove unnecessary rm instances doc: improve asciidoc dependencies doc: refactor common asciidoc dependencies
2021-06-14Merge branch 'so/log-m-implies-p'Libravatar Junio C Hamano1-4/+4
The "-m" option in "git log -m" that does not specify which format, if any, of diff is desired did not have any visible effect; it now implies some form of diff (by default "--patch") is produced. * so/log-m-implies-p: diff-merges: let "-m" imply "-p" diff-merges: rename "combined_imply_patch" to "merges_imply_patch" stash list: stop passing "-m" to "git log" git-svn: stop passing "-m" to "git rev-list" diff-merges: move specific diff-index "-m" handling to diff-index t4013: test "git diff-index -m" t4013: test "git diff-tree -m" t4013: test "git log -m --stat" t4013: test "git log -m --raw" t4013: test that "-m" alone has no effect in "git log"
2021-06-14Merge branch 'en/ort-perf-batch-11'Libravatar Junio C Hamano1-0/+671
Optimize out repeated rename detection in a sequence of mergy operations. * en/ort-perf-batch-11: merge-ort, diffcore-rename: employ cached renames when possible merge-ort: handle interactions of caching and rename/rename(1to1) cases merge-ort: add helper functions for using cached renames merge-ort: preserve cached renames for the appropriate side merge-ort: avoid accidental API mis-use merge-ort: add code to check for whether cached renames can be reused merge-ort: populate caches of rename detection results merge-ort: add data structures for in-memory caching of rename detection t6429: testcases for remembering renames fast-rebase: write conflict state to working tree, index, and HEAD fast-rebase: change assert() to BUG() Documentation/technical: describe remembering renames optimization t6423: rename file within directory that other side renamed
2021-06-14Merge branch 'ga/send-email-sendmail-cmd'Libravatar Junio C Hamano1-7/+18
"git send-email" learned the "--sendmail-cmd" command line option and the "sendemail.sendmailCmd" configuration variable, which is a more sensible approach than the current way of repurposing the "smtp-server" that is meant to name the server to instead name the command to talk to the server. * ga/send-email-sendmail-cmd: git-send-email: add option to specify sendmail command
2021-06-10The first batch post Git 2.32Libravatar Junio C Hamano1-0/+32
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-10Merge branch 'jk/doc-color-pager'Libravatar Junio C Hamano1-2/+3
The documentation for "color.pager" configuration variable has been updated. * jk/doc-color-pager: doc: explain the use of color.pager
2021-06-10Merge branch 'tl/fix-packfile-uri-doc'Libravatar Junio C Hamano1-7/+8
Doc fix. * tl/fix-packfile-uri-doc: packfile-uri.txt: fix blobPackfileUri description
2021-06-10Merge branch 'ry/clarify-fast-forward-in-glossary'Libravatar Junio C Hamano1-2/+2
The description of "fast-forward" in the glossary has been updated. * ry/clarify-fast-forward-in-glossary: docs: improve fast-forward in glossary content
2021-06-10Merge branch 'jc/clarify-revision-range'Libravatar Junio C Hamano1-0/+23
Doc update. * jc/clarify-revision-range: revisions(7): clarify that most commands take a single revision range
2021-06-10Merge branch 'ah/doc-describe'Libravatar Junio C Hamano1-5/+9
Doc update. * ah/doc-describe: describe-doc: clarify default length of abbreviation
2021-05-25packfile-uri.txt: fix blobPackfileUri descriptionLibravatar Teng Long1-7/+8
Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt and the correct format also can be seen in t5702. Signed-off-by: Teng Long <dyroneteng@gmail.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: avoid using rm directlyLibravatar Felipe Contreras1-3/+3
That's what we have $(RM) for. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: simplify Makefile using .DELETE_ON_ERRORLibravatar Felipe Contreras1-28/+19
Currently GNU make already removes files when catching an interruption signal, however, in order to deal with other kinds of errors a workaround is in place to store target output to a temporary file, and only move it to its right place on success. By enabling the built-in .DELETE_ON_ERROR we let make do this task, so we don't have to. This way the rules can be simplified a lot. Suggested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: remove unnecessary rm instancesLibravatar Felipe Contreras1-27/+15
Commits 50cff52f1a (When generating manpages, delete outdated targets first., 2007-08-02) and f9286765b2 (Documentation/Makefile: remove cmd-list.made before redirecting to it., 2007-08-06) created these rm instances for a very rare corner-case: building as root by mistake. It's odd to have workarounds here, but nowhere else in the Makefile-- which already fails in this stuation, starting from Documentation/technical/. We gain nothing but complexity, so let's remove them. Comments-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: improve asciidoc dependenciesLibravatar Felipe Contreras1-1/+2
asciidoc needs asciidoc.conf, asciidoctor asciidoctor-extensions.rb. Neither needs the other. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: refactor common asciidoc dependenciesLibravatar Felipe Contreras1-3/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-22Git 2.32-rc1Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-22Merge branch 'dl/stash-show-untracked-fixup'Libravatar Junio C Hamano2-5/+7
Another brown paper bag inconsistency fix for a new feature introduced during this cycle. * dl/stash-show-untracked-fixup: stash show: use stash.showIncludeUntracked even when diff options given
2021-05-22stash show: use stash.showIncludeUntracked even when diff options givenLibravatar Denton Liu2-5/+7
If options pertaining to how the diff is displayed is provided to `git stash show`, the command will ignore the stash.showIncludeUntracked configuration variable, defaulting to not showing any untracked files. This is unintuitive behaviour since the format of the diff output and whether or not to display untracked files are orthogonal. Use stash.showIncludeUntracked even when diff options are given. Of course, this is still overridable via the command-line options. Update the documentation to explicitly say which configuration variables will be overridden when a diff options are given. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21diff-merges: let "-m" imply "-p"Libravatar Sergey Organov1-4/+4
Fix long standing inconsistency between -c/--cc that do imply -p on one side, and -m that did not imply -p on the other side. Change corresponding test accordingly, as "log -m" output should now match one from "log -m -p", rather than from just "log". Change documentation accordingly. NOTES: After this patch git log -m produces diffs without need to provide -p as well, that improves both consistency and usability. It gets even more useful if one sets "log.diffMerges" configuration variable to "first-parent" to force -m produce usual diff with respect to first parent only. This patch, however, does not change behavior when specific diff format is explicitly provided on the command-line, so that commands like git log -m --raw git log -m --stat are not affected, nor does it change commands where specific diff format is active by default, such as: git diff-tree -m It's also worth to be noticed that exact historical semantics of -m is still provided by --diff-merges=separate. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21Merge branch 'cs/http-use-basic-after-failed-negotiate'Libravatar Junio C Hamano1-5/+0
Regression fix for a change made during this cycle. * cs/http-use-basic-after-failed-negotiate: Revert "remote-curl: fall back to basic auth if Negotiate fails" t5551: test http interaction with credential helpers
2021-05-20t6429: testcases for remembering renamesLibravatar Elijah Newren1-6/+8
We will soon be adding an optimization that caches (in memory only, never written to disk) upstream renames during a sequence of merges such as occurs during a cherry-pick or rebase operation. Add several tests meant to stress such an implementation to ensure it does the right thing, and include a test whose outcome we will later change due to this optimization as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-20Documentation/technical: describe remembering renames optimizationLibravatar Elijah Newren1-0/+669
Remembering renames on the upstream side of history in an early merge of a rebase or cherry-pick for re-use in a latter merge of the same operation makes pretty good intuitive sense. However, trying to show that it doesn't cause some subtle behavioral difference or some funny edge or corner case is much more involved. And, in fact, it does introduce a subtle behavioral change. Document all the assumptions, special cases, and logic involved in such an optimization, and describe why this optimization is safe under the current optimizations/features/etc. -- even when the subtle behavioral change is triggered. Part of the point of adding this document that goes over the optimization in such laborious detail, is that it is possible that significant future changes (optimizations or feature changes) could interact with this optimization in interesting ways; this document is here to help folks making big changes sanity check that the assumptions and arguments underlying this optimization are still valid. (As a side note, creating this document forced me to review things in sufficient detail that I found I was not properly caching directory-rename-induced renames, resulting in the code not being aware of those renames and causing unnecessary diffcore_rename_extended() calls in subsequent merges.) A subsequent commit will add several testcases based on this document meant to stress-test the implementation and also document the case with the subtle behavioral change. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-20doc: explain the use of color.pagerLibravatar Jeff King1-2/+3
The current documentation for color.pager is technically correct, but slightly misleading and doesn't really clarify the purpose of the variable. As explained in the original thread which added it: https://lore.kernel.org/git/E1G6zPH-00062L-Je@moooo.ath.cx/ the point is to deal with pagers that don't understand colors. And hence it being set to "true" is necessary for colorizing output to the pager, but not sufficient by itself (you must also have enabled one of the other color options, though note that these are set to "auto" by default these days). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-20A handful more topics before -rc1Libravatar Junio C Hamano1-0/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-19docs: improve fast-forward in glossary contentLibravatar Reuven Y1-2/+2
The text was somewhat confusing between the revision itself and the author. Signed-off-by: Reuven Yagel <robi@post.jce.ac.il> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-18revisions(7): clarify that most commands take a single revision rangeLibravatar Junio C Hamano1-0/+23
Sometimes new people are confused by how a revision "range" works, in that it is not a random collection of commits but a set of commits that are all connected to each other, and most Git commands work on a single such "range". Give an example to clarify it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-17describe-doc: clarify default length of abbreviationLibravatar Anders Höckersten1-5/+9
Clarify the default length used for the abbreviated form used for commits in git describe. The behavior was modified in Git 2.11.0, but the documentation was not updated to clarify the new behavior. Signed-off-by: Anders Höckersten <anders@hockersten.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-17git-send-email: add option to specify sendmail commandLibravatar Gregory Anders1-7/+18
The sendemail.smtpServer configuration option and --smtp-server command line option both support using a sendmail-like program to send emails by specifying an absolute file path. However, this is not ideal for the following reasons: 1. It overloads the meaning of smtpServer (now a program is being used for the server?) 2. It doesn't allow for non-absolute paths, arguments, or arbitrary scripting Requiring an absolute path is bad for portability, as the same program may be in different locations on different systems. If a user wishes to pass arguments to their program, they have to use the smtpServerOption option, which is cumbersome (as it must be repeated for each option) and doesn't adhere to normal git conventions. Introduce a new configuration option sendemail.sendmailCmd as well as a command line option --sendmail-cmd that can be used to specify a command (with or without arguments) or shell expression to run to send email. The name of this option is consistent with --to-cmd and --cc-cmd. This invocation honors the user's $PATH so that absolute paths are not necessary. Arbitrary shell expressions are also supported, allowing users to do basic scripting. Give this option a higher precedence over --smtp-server and sendemail.smtpServer, as the new interface is more flexible. For backward compatibility, continue to support absolute paths in --smtp-server and sendemail.smtpServer. Signed-off-by: Gregory Anders <greg@gpanders.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-16Git 2.32-rc0Libravatar Junio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-16Merge branch 'ls/typofix'Libravatar Junio C Hamano1-1/+1
* ls/typofix: pretty: fix a typo in the documentation for %(trailers)
2021-05-16Merge branch 'ma/typofixes'Libravatar Junio C Hamano2-2/+2
A couple of trivial typofixes. * ma/typofixes: pretty-formats.txt: add missing space git-repack.txt: remove spurious ")"
2021-05-16Merge branch 'dd/mailinfo-quoted-cr'Libravatar Junio C Hamano2-1/+24
"git mailinfo" (hence "git am") learned the "--quoted-cr" option to control how lines ending with CRLF wrapped in base64 or qp are handled. * dd/mailinfo-quoted-cr: am: learn to process quoted lines that ends with CRLF mailinfo: allow stripping quoted CR without warning mailinfo: allow squelching quoted CRLF warning mailinfo: warn if CRLF found in decoded base64/QP email mailinfo: stop parsing options manually mailinfo: load default metainfo_charset lazily
2021-05-16Merge branch 'jt/push-negotiation'Libravatar Junio C Hamano2-0/+15
"git push" learns to discover common ancestor with the receiving end over protocol v2. * jt/push-negotiation: send-pack: support push negotiation fetch: teach independent negotiation (no packfile) fetch-pack: refactor command and capability write fetch-pack: refactor add_haves() fetch-pack: refactor process_acks()
2021-05-14The seventeenth batchLibravatar Junio C Hamano1-0/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-14Merge branch 'ba/object-info'Libravatar Junio C Hamano1-0/+31
Over-the-wire protocol learns a new request type to ask for object sizes given a list of object names. * ba/object-info: object-info: support for retrieving object info
2021-05-13pretty: fix a typo in the documentation for %(trailers)Libravatar Louis Sautier1-1/+1
Signed-off-by: Louis Sautier <sautier.louis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11The sixteenth batchLibravatar Junio C Hamano1-0/+26
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-11Merge branch 'zh/trailer-cmd'Libravatar Junio C Hamano1-16/+78
The way the command line specified by the trailer.<token>.command configuration variable receives the end-user supplied value was both error prone and misleading. An alternative to achieve the same goal in a safer and more intuitive way has been added, as the trailer.<token>.cmd configuration variable, to replace it. * zh/trailer-cmd: trailer: add new .cmd config option docs: correct descript of trailer.<token>.command
2021-05-11Merge branch 'jk/symlinked-dotgitx-cleanup'Libravatar Junio C Hamano4-0/+25
Various test and documentation updates about .gitsomething paths that are symlinks. * jk/symlinked-dotgitx-cleanup: docs: document symlink restrictions for dot-files fsck: warn about symlinked dotfiles we'll open with O_NOFOLLOW t0060: test ntfs/hfs-obscured dotfiles t7450: test .gitmodules symlink matching against obscured names t7450: test verify_path() handling of gitmodules t7415: rename to expand scope fsck_tree(): wrap some long lines fsck_tree(): fix shadowed variable t7415: remove out-dated comment about translation
2021-05-11Merge branch 'jk/doc-format-patch-skips-merges'Libravatar Junio C Hamano1-1/+9
Document that "format-patch" skips merges. * jk/doc-format-patch-skips-merges: docs/format-patch: mention handling of merges
2021-05-11Merge branch 'jc/test-allows-local'Libravatar Junio C Hamano1-0/+5
Document that our test can use "local" keyword. * jc/test-allows-local: CodingGuidelines: explicitly allow "local" for test scripts
2021-05-10The fifteenth batchLibravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10am: learn to process quoted lines that ends with CRLFLibravatar Đoàn Trần Công Danh1-0/+4
In previous changes, mailinfo has learnt to process lines that decoded from base64 or quoted-printable, and ends with CRLF. Let's teach "am" that new trick, too. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10mailinfo: allow stripping quoted CR without warningLibravatar Đoàn Trần Công Danh1-0/+1
In previous changes, we've turned on warning for quoted CR in base64 or quoted-printable email messages. Some projects see those quoted CR a lot, they know that it happens most of the time, and they find it's desirable to always strip those CR. Those projects in question usually fall back to use other tools to handle patches when receive such patches. Let's help those projects handle those patches by stripping those excessive CR. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10mailinfo: allow squelching quoted CRLF warningLibravatar Đoàn Trần Công Danh1-1/+19
In previous change, Git starts to warn for quoted CRLF in decoded base64/QP email. Despite those warnings are usually helpful, quoted CRLF could be part of some users' workflow. Let's give them an option to turn off the warning completely. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10pretty-formats.txt: add missing spaceLibravatar Martin Ågren1-1/+1
The description of "%ch" is missing a space after "human style", before the parenthetical remark. This description was introduced in b722d4560e ("pretty: provide human date format", 2021-04-25). That commit also added "%ah", which does have the space already. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>