summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2019-02-06Merge branch 'ma/doc-diff-usage-fix'Libravatar Junio C Hamano1-3/+2
Running "Documentation/doc-diff x" from anywhere other than the top-level of the working tree did not show the usage string correctly, which has been fixed. * ma/doc-diff-usage-fix: doc-diff: don't `cd_to_toplevel`
2019-02-06Merge branch 'ab/diff-tree-doc-fix'Libravatar Junio C Hamano1-50/+1
Doc fix. * ab/diff-tree-doc-fix: diff-tree doc: correct & remove wrong documentation
2019-02-06Merge branch 'nd/commit-doc'Libravatar Junio C Hamano1-7/+11
Doc update. * nd/commit-doc: git-commit.txt: better description what it does
2019-02-06Merge branch 'jk/loose-object-cache-oid'Libravatar Junio C Hamano1-3/+3
Code clean-up. * jk/loose-object-cache-oid: prefer "hash mismatch" to "sha1 mismatch" sha1-file: avoid "sha1 file" for generic use in messages sha1-file: prefer "loose object file" to "sha1 file" in messages sha1-file: drop has_sha1_file() convert has_sha1_file() callers to has_object_file() sha1-file: convert pass-through functions to object_id sha1-file: modernize loose header/stream functions sha1-file: modernize loose object file functions http: use struct object_id instead of bare sha1 update comment references to sha1_object_info() sha1-file: fix outdated sha1 comment references
2019-02-06Merge branch 'ds/push-sparse-tree-walk'Libravatar Junio C Hamano2-1/+19
"git pack-objects" learned another algorithm to compute the set of objects to send, that trades the resulting packfile off to save traversal cost to favor small pushes. * ds/push-sparse-tree-walk: pack-objects: create GIT_TEST_PACK_SPARSE pack-objects: create pack.useSparse setting revision: implement sparse algorithm list-objects: consume sparse tree walk revision: add mark_tree_uninteresting_sparse
2019-02-06Merge branch 'lt/date-human'Libravatar Junio C Hamano2-0/+11
A new date format "--date=human" that morphs its output depending on how far the time is from the current time has been introduced. "--date=auto" can be used to use this new format when the output is going to the pager or to the terminal and otherwise the default format. * lt/date-human: Add `human` date format tests. Add `human` format to test-tool Add 'human' date format documentation Replace the proposed 'auto' mode with 'auto:' Add 'human' date format
2019-02-06Merge branch 'jk/autocrlf-overrides-eol-doc'Libravatar Junio C Hamano2-3/+8
Documentation around core.crlf has been updated. * jk/autocrlf-overrides-eol-doc: docs/config: clarify "text property" in core.eol doc/gitattributes: clarify "autocrlf overrides eol"
2019-02-06Merge branch 'tb/utf-16-le-with-explicit-bom'Libravatar Junio C Hamano1-1/+3
A new encoding UTF-16LE-BOM has been invented to force encoding to UTF-16 with BOM in little endian byte order, which cannot be directly generated by using iconv. * tb/utf-16-le-with-explicit-bom: Support working-tree-encoding "UTF-16LE-BOM"
2019-02-06Merge branch 'dt/cat-file-batch-ambiguous'Libravatar Junio C Hamano1-0/+6
"git cat-file --batch" reported a dangling symbolic link by mistake, when it wanted to report that a given name is ambiguous. * dt/cat-file-batch-ambiguous: t1512: test ambiguous cat-file --batch and --batch-output Do not print 'dangling' for cat-file in case of ambiguity
2019-02-06Merge branch 'km/init-doc-typofix'Libravatar Junio C Hamano1-1/+1
Docfix. * km/init-doc-typofix: init docs: correct a punctuation typo
2019-02-06Merge branch 'en/rebase-merge-on-sequencer'Libravatar Junio C Hamano1-14/+3
"git rebase --merge" as been reimplemented by reusing the internal machinery used for "git rebase -i". * en/rebase-merge-on-sequencer: rebase: implement --merge via the interactive machinery rebase: define linearization ordering and enforce it git-legacy-rebase: simplify unnecessary triply-nested if git-rebase, sequencer: extend --quiet option for the interactive machinery am, rebase--merge: do not overlook --skip'ed commits with post-rewrite t5407: add a test demonstrating how interactive handles --skip differently rebase: fix incompatible options error message rebase: make builtin and legacy script error messages the same
2019-02-05Fifth batch for 2.21Libravatar Junio C Hamano1-0/+90
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'az/instaweb-py3-http-server'Libravatar Junio C Hamano1-1/+2
"git instaweb" learned to drive http.server that comes with "batteries included" Python installation (both Python2 & 3). * az/instaweb-py3-http-server: git-instaweb: add Python builtin http.server support
2019-02-05Merge branch 'ja/doc-style-fix'Libravatar Junio C Hamano14-94/+93
Doc typo/stylo fixes. * ja/doc-style-fix: doc: tidy asciidoc style
2019-02-05Merge branch 'ab/commit-graph-write-progress'Libravatar Junio C Hamano1-2/+2
The codepath to show progress meter while writing out commit-graph file has been improved. * ab/commit-graph-write-progress: commit-graph write: emit a percentage for all progress commit-graph write: add itermediate progress commit-graph write: remove empty line for readability commit-graph write: add more descriptive progress output commit-graph write: show progress for object search commit-graph write: more descriptive "writing out" output commit-graph write: add "Writing out" progress output commit-graph: don't call write_graph_chunk_extra_edges() unnecessarily commit-graph: rename "large edges" to "extra edges"
2019-02-05Merge branch 'jt/fetch-v2-sideband'Libravatar Junio C Hamano2-9/+21
"git fetch" and "git upload-pack" learned to send all exchange over the sideband channel while talking the v2 protocol. * jt/fetch-v2-sideband: tests: define GIT_TEST_SIDEBAND_ALL {fetch,upload}-pack: sideband v2 fetch response sideband: reverse its dependency on pkt-line pkt-line: introduce struct packet_writer pack-protocol.txt: accept error packets in any context Use packet_reader instead of packet_read_line
2019-02-05Merge branch 'js/filter-options-should-use-plain-int'Libravatar Junio C Hamano2-3/+14
Update the protocol message specification to allow only the limited use of scaled quantities. This is ensure potential compatibility issues will not go out of hand. * js/filter-options-should-use-plain-int: filter-options: expand scaled numbers tree:<depth>: skip some trees even when collecting omits list-objects-filter: teach tree:# how to handle >0
2019-02-04doc-diff: don't `cd_to_toplevel`Libravatar Martin Ågren1-3/+2
`usage` tries to call $0, which might very well be "./doc-diff", so if we `cd_to_toplevel` before calling `usage`, we'll end with an error to the effect of "./doc-diff: not found" rather than a friendly `doc-diff -h` output. This regressed in ad51743007 ("doc-diff: add --clean mode to remove temporary working gunk", 2018-08-31) where we moved the call to `cd_to_toplevel` to much earlier. A general fix might be to teach git-sh-setup to save away the absolute path for $0 and then use that, instead. I'm not aware of any portable way of doing that, see, e.g., d2addc3b96 ("t7800: readlink may not be available", 2016-05-31). An early version of this patch moved `cd_to_toplevel` back to where it was before ad51743007 and taught the "--clean" code to cd on its own. But let's try instead to get rid of the cd-ing entirely. We don't really need it and we can work with absolute paths instead. There's just one use of $PWD that we need to adjust by simply dropping it. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-04diff-tree doc: correct & remove wrong documentationLibravatar Ævar Arnfjörð Bjarmason1-50/+1
The documentation saying that diff-tree didn't support anything except literal prefixes hasn't been true since d38f28093e ("tree_entry_interesting(): support wildcard matching", 2010-12-15), but this documentation was not updated at the time. Since this command uses pathspecs like most other commands, there's no need to show examples of how the various "cmd <revs> <paths>" invocations work. Furthermore, the "git diff-tree --abbrev 5319e4" example shown here never worked. We'd ended up with that through a combination of 62b42d3487 ("docs: fix some antique example output", 2011-05-26) and ac4e086929 ("Adjust core-git documentation to more recent Linus GIT.", 2005-05-05), but "git diff-tree <tree>" was always invalid. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-04git-commit.txt: better description what it doesLibravatar Nguyễn Thái Ngọc Duy1-7/+11
The description of git-commit jumps right into the commit content, which is important, but it fails to mention how the commit is "added" to the repository. Update the first paragraph saying a bit more about branch update to fill this gap. While at there, add a couple linkgit references when the command is first mentioned. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-31Support working-tree-encoding "UTF-16LE-BOM"Libravatar Torsten Bögershausen1-1/+3
Users who want UTF-16 files in the working tree set the .gitattributes like this: test.txt working-tree-encoding=UTF-16 The unicode standard itself defines 3 allowed ways how to encode UTF-16. The following 3 versions convert all back to 'g' 'i' 't' in UTF-8: a) UTF-16, without BOM, big endian: $ printf "\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t b) UTF-16, with BOM, little endian: $ printf "\377\376g\000i\000t\000" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t c) UTF-16, with BOM, big endian: $ printf "\376\377\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t Git uses libiconv to convert from UTF-8 in the index into ITF-16 in the working tree. After a checkout, the resulting file has a BOM and is encoded in "UTF-16", in the version (c) above. This is what iconv generates, more details follow below. iconv (and libiconv) can generate UTF-16, UTF-16LE or UTF-16BE: d) UTF-16 $ printf 'git' | iconv -f UTF-8 -t UTF-16 | od -c 0000000 376 377 \0 g \0 i \0 t e) UTF-16LE $ printf 'git' | iconv -f UTF-8 -t UTF-16LE | od -c 0000000 g \0 i \0 t \0 f) UTF-16BE $ printf 'git' | iconv -f UTF-8 -t UTF-16BE | od -c 0000000 \0 g \0 i \0 t There is no way to generate version (b) from above in a Git working tree, but that is what some applications need. (All fully unicode aware applications should be able to read all 3 variants, but in practise we are not there yet). When producing UTF-16 as an output, iconv generates the big endian version with a BOM. (big endian is probably chosen for historical reasons). iconv can produce UTF-16 files with little endianess by using "UTF-16LE" as encoding, and that file does not have a BOM. Not all users (especially under Windows) are happy with this. Some tools are not fully unicode aware and can only handle version (b). Today there is no way to produce version (b) with iconv (or libiconv). Looking into the history of iconv, it seems as if version (c) will be used in all future iconv versions (for compatibility reasons). Solve this dilemma and introduce a Git-specific "UTF-16LE-BOM". libiconv can not handle the encoding, so Git pick it up, handles the BOM and uses libiconv to convert the rest of the stream. (UTF-16BE-BOM is added for consistency) Rported-by: Adrián Gimeno Balaguer <adrigibal@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-31init docs: correct a punctuation typoLibravatar Kyle Meyer1-1/+1
Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29Fourth batch after 2.20Libravatar Junio C Hamano1-0/+54
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29Merge branch 'it/log-format-source'Libravatar Junio C Hamano1-0/+2
Custom userformat "log --format" learned %S atom that stands for the tip the traversal reached the commit from, i.e. --source. * it/log-format-source: log: add %S option (like --source) to log --format
2019-01-29Merge branch 'sb/submodule-recursive-fetch-gets-the-tip'Libravatar Junio C Hamano1-0/+5
"git fetch --recurse-submodules" may not fetch the necessary commit that is bound to the superproject, which is getting corrected. * sb/submodule-recursive-fetch-gets-the-tip: fetch: ensure submodule objects fetched submodule.c: fetch in submodules git directory instead of in worktree submodule: migrate get_next_submodule to use repository structs repository: repo_submodule_init to take a submodule struct submodule: store OIDs in changed_submodule_names submodule.c: tighten scope of changed_submodule_names struct submodule.c: sort changed_submodule_names before searching it submodule.c: fix indentation sha1-array: provide oid_array_filter
2019-01-29Merge branch 'pw/diff-color-moved-ws-fix'Libravatar Junio C Hamano2-6/+17
"git diff --color-moved-ws" updates. * pw/diff-color-moved-ws-fix: diff --color-moved-ws: handle blank lines diff --color-moved-ws: modify allow-indentation-change diff --color-moved-ws: optimize allow-indentation-change diff --color-moved=zebra: be stricter with color alternation diff --color-moved-ws: fix false positives diff --color-moved-ws: demonstrate false positives diff: allow --no-color-moved-ws Use "whitespace" consistently diff: document --no-color-moved
2019-01-29Merge branch 'ja/doc-build-l10n'Libravatar Junio C Hamano1-5/+17
Prepare Documentation/Makefile so that manpage localization can reuse it by overriding and tweaking the list of build products. * ja/doc-build-l10n: Documentation/Makefile add optional targets for l10n
2019-01-29Merge branch 'js/rebase-i-redo-exec'Libravatar Junio C Hamano2-0/+16
"git rebase -i" learned to re-execute a command given with 'exec' to run after it failed the last time. * js/rebase-i-redo-exec: rebase: introduce a shortcut for --reschedule-failed-exec rebase: add a config option to default to --reschedule-failed-exec rebase: introduce --reschedule-failed-exec
2019-01-29Merge branch 'cc/partial-clone-doc-typofix'Libravatar Junio C Hamano1-1/+1
Doc fix. * cc/partial-clone-doc-typofix: partial-clone: add missing 'is' in doc
2019-01-29docs/config: clarify "text property" in core.eolLibravatar Jeff King1-2/+5
The word "property" is vague here. Let's spell out that we mean the path must be marked with the text attribute. While we're here, let's make the paragraph a little easier to read by de-emphasizing the "when core.autocrlf is false" bit. Putting it in the first sentence obscures the main content, and many readers won't care about autocrlf (i.e., anyone who is just following the gitattributes(7) advice, which mainly discusses "text" and "core.eol"). Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29doc/gitattributes: clarify "autocrlf overrides eol"Libravatar Jeff King1-1/+3
We only override core.eol with core.autocrlf when the latter is set to something besides "false". Let's make this more clear, and point the reader to the git-config definitions, which discuss this in more detail. Noticed-by: Sergey Lukashev <lukashev.s@ya.ru> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-28git-instaweb: add Python builtin http.server supportLibravatar Arti Zirk1-1/+2
With this patch it is possible to launch git-instaweb by using Python http.server CGI handler via `-d python` option. git-instaweb generates a small wrapper around the http.server (in GIT_DIR/gitweb/) that address a limitation of the CGI handler where CGI scripts have to be in a cgi-bin subdirectory and directory index can't be easily changed. To keep the implementation small, gitweb is running on url `/cgi-bin/gitweb.cgi` and an automatic redirection is done when opening `/`. The generated wrapper is compatible with both Python 2 and 3. Python is by default installed on most modern Linux distributions which enables running `git instaweb -d python` without needing anything else. Signed-off-by: Arti Zirk <arti.zirk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-23doc: tidy asciidoc styleLibravatar Jean-Noël Avila14-94/+93
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22Add 'human' date format documentationLibravatar Stephen P. Smith2-0/+11
Display date and time information in a format similar to how people write dates in other contexts. If the year isn't specified then, the reader infers the date is given is in the current year. By not displaying the redundant information, the reader concentrates on the information that is different. The patch reports relative dates based on information inferred from the date on the machine running the git command at the time the command is executed. While the format is more useful to humans by dropping inferred information, there is nothing that makes it actually human. If the 'relative' date format wasn't already implemented then using 'relative' would have been appropriate. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22commit-graph: rename "large edges" to "extra edges"Libravatar SZEDER Gábor1-2/+2
The optional 'Large Edge List' chunk of the commit graph file stores parent information for commits with more than two parents, and the names of most of the macros, variables, struct fields, and functions related to this chunk contain the term "large edges", e.g. write_graph_chunk_large_edges(). However, it's not a really great term, as the edges to the second and subsequent parents stored in this chunk are not any larger than the edges to the first and second parents stored in the "main" 'Commit Data' chunk. It's the number of edges, IOW number of parents, that is larger compared to non-merge and "regular" two-parent merge commits. And indeed, two functions in 'commit-graph.c' have a local variable called 'num_extra_edges' that refer to the same thing, and this "extra edges" term is much better at describing these edges. So let's rename all these references to "large edges" in macro, variable, function, etc. names to "extra edges". There is a GRAPH_OCTOPUS_EDGES_NEEDED macro as well; for the sake of consistency rename it to GRAPH_EXTRA_EDGES_NEEDED. We can do so safely without causing any incompatibility issues, because the term "large edges" doesn't come up in the file format itself in any form (the chunk's magic is {'E', 'D', 'G', 'E'}, there is no 'L' in there), but only in the specification text. The string "large edges", however, does come up in the output of 'git commit-graph read' and in tests looking at its input, but that command is explicitly documented as debugging aid, so we can change its output and the affected tests safely. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Do not print 'dangling' for cat-file in case of ambiguityLibravatar David Turner1-0/+6
The return values -1 and -2 from get_oid could mean two different things, depending on whether they were from an enum returned by get_tree_entry_follow_symlinks, or from a different code path. This caused 'dangling' to be printed from a git cat-file in the case of an ambiguous (-2) result. Unify the results of get_oid* and get_tree_entry_follow_symlinks to be one common type, with unambiguous values. Signed-off-by: David Turner <novalis@novalis.org> Reported-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Third batch after 2.20Libravatar Junio C Hamano1-0/+80
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Merge branch 'en/show-ref-doc-fix'Libravatar Junio C Hamano1-1/+1
Doc update. * en/show-ref-doc-fix: git-show-ref.txt: fix order of flags
2019-01-18Merge branch 'ot/ref-filter-object-info'Libravatar Junio C Hamano1-1/+20
The "--format=<placeholder>" option of for-each-ref, branch and tag learned to show a few more traits of objects that can be learned by the object_info API. * ot/ref-filter-object-info: ref-filter: give uintmax_t to format with %PRIuMAX ref-filter: add docs for new options ref-filter: add tests for deltabase ref-filter: add deltabase option ref-filter: add tests for objectsize:disk ref-filter: add check for negative file size ref-filter: add objectsize:disk option
2019-01-18Merge branch 'es/doc-worktree-guessremote-config'Libravatar Junio C Hamano1-2/+2
Doc clarification. * es/doc-worktree-guessremote-config: doc/config: do a better job of introducing 'worktree.guessRemote'
2019-01-18Merge branch 'ma/asciidoctor'Libravatar Junio C Hamano4-86/+86
Some of the documentation pages formatted incorrectly with Asciidoctor, which have been fixed. * ma/asciidoctor: git-status.txt: render tables correctly under Asciidoctor Documentation: do not nest open blocks git-column.txt: fix section header
2019-01-18Merge branch 'la/quiltimport-keep-non-patch'Libravatar Junio C Hamano1-1/+4
"git quiltimport" learned "--keep-non-patch" option. * la/quiltimport-keep-non-patch: git-quiltimport: add --keep-non-patch option
2019-01-18Merge branch 'ds/gc-doc-typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * ds/gc-doc-typofix: git-gc.txt: fix typo about gc.writeCommitGraph
2019-01-17pack-objects: create pack.useSparse settingLibravatar Derrick Stolee1-0/+9
The '--sparse' flag in 'git pack-objects' changes the algorithm used to enumerate objects to one that is faster for individual users pushing new objects that change only a small cone of the working directory. The sparse algorithm is not recommended for a server, which likely sends new objects that appear across the entire working directory. Create a 'pack.useSparse' setting that enables this new algorithm. This allows 'git push' to use this algorithm without passing a '--sparse' flag all the way through four levels of run_command() calls. If the '--no-sparse' flag is set, then this config setting is overridden. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17list-objects: consume sparse tree walkLibravatar Derrick Stolee1-1/+10
When creating a pack-file using 'git pack-objects --revs' we provide a list of interesting and uninteresting commits. For example, a push operation would make the local topic branch be interesting and the known remote refs as uninteresting. We want to discover the set of new objects to send to the server as a thin pack. We walk these commits until we discover a frontier of commits such that every commit walk starting at interesting commits ends in a root commit or unintersting commit. We then need to discover which non-commit objects are reachable from uninteresting commits. This commit walk is not changing during this series. The mark_edges_uninteresting() method in list-objects.c iterates on the commit list and does the following: * If the commit is UNINTERSTING, then mark its root tree and every object it can reach as UNINTERESTING. * If the commit is interesting, then mark the root tree of every UNINTERSTING parent (and all objects that tree can reach) as UNINTERSTING. At the very end, we repeat the process on every commit directly given to the revision walk from stdin. This helps ensure we properly cover shallow commits that otherwise were not included in the frontier. The logic to recursively follow trees is in the mark_tree_uninteresting() method in revision.c. The algorithm avoids duplicate work by not recursing into trees that are already marked UNINTERSTING. Add a new 'sparse' option to the mark_edges_uninteresting() method that performs this logic in a slightly different way. As we iterate over the commits, we add all of the root trees to an oidset. Then, call mark_trees_uninteresting_sparse() on that oidset. Note that we include interesting trees in this process. The current implementation of mark_trees_unintersting_sparse() will walk the same trees as the old logic, but this will be replaced in a later change. Add a '--sparse' flag in 'git pack-objects' to call this new logic. Add a new test script t/t5322-pack-objects-sparse.sh that tests this option. The tests currently demonstrate that the resulting object list is the same as the old algorithm. This includes a case where both algorithms pack an object that is not needed by a remote due to limits on the explored set of trees. When the sparse algorithm is changed in a later commit, we will add a test that demonstrates a change of behavior in some cases. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17{fetch,upload}-pack: sideband v2 fetch responseLibravatar Jonathan Tan1-0/+10
Currently, a response to a fetch request has sideband support only while the packfile is being sent, meaning that the server cannot send notices until the start of the packfile. Extend sideband support in protocol v2 fetch responses to the whole response. upload-pack will advertise it if the uploadpack.allowsidebandall configuration variable is set, and fetch-pack will automatically request it if advertised. If the sideband is to be used throughout the whole response, upload-pack will use it to send errors instead of prefixing a PKT-LINE payload with "ERR ". This will be tested in a subsequent patch. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-15filter-options: expand scaled numbersLibravatar Josh Steadmon1-1/+7
When communicating with a remote server or a subprocess, use expanded numbers rather than numbers with scaling suffix in the object filter spec (e.g. "limit:blob=1k" becomes "limit:blob=1024"). Update the protocol docs to note that clients should always perform this expansion, to allow for more compatibility between server implementations. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-15list-objects-filter: teach tree:# how to handle >0Libravatar Matthew DeVore1-2/+7
Implement positive values for <depth> in the tree:<depth> filter. The exact semantics are described in Documentation/rev-list-options.txt. The long-term goal at the end of this is to allow a partial clone to eagerly fetch an entire directory of files by fetching a tree and specifying <depth>=1. This, for instance, would make a build operation fast and convenient. It is fast because the partial clone does not need to fetch each file individually, and convenient because the user does not need to supply a sparse-checkout specification. Another way of considering this feature is as a way to reduce round-trips, since the client can get any number of levels of directories in a single request, rather than wait for each level of tree objects to come back, whose entries are used to construct a new request. Signed-off-by: Matthew DeVore <matvore@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-14Second batch after 2.20Libravatar Junio C Hamano1-0/+42
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-14Merge branch 'do/gitweb-strict-export-conf-doc'Libravatar Junio C Hamano1-2/+2
Doc update. * do/gitweb-strict-export-conf-doc: docs: fix $strict_export text in gitweb.conf.txt