summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-09-22rebase: dereference tagsPhillip Wood2-10/+22
A rebase started with 'git rebase <A> <B>' is conceptually to first checkout <B> and run 'git rebase <A>' starting from that state. 'git rebase --abort' in the middle of such a rebase should take us back to the state we checked out <B>. This used to work, even when <B> is a tag that points at a commit, until Git 2.20.0 when the command was reimplemented in C. The command now complains that the tag object itself cannot be checked out, which may be technically correct but is not what the user asked to do. Fix this old regression by using lookup_commit_reference_by_name() when parsing <B>. The scripted version did not need to peel the tag because the commands it passed the tag to (e.g 'git reset') peeled the tag themselves. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22rebase: use lookup_commit_reference_by_name()Phillip Wood1-13/+4
peel_committish() appears to have been copied from the scripted rebase but it duplicates the functionality of lookup_commit_reference_by_name() so lets use that instead. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22rebase: use our standard error return valuePhillip Wood1-9/+9
Git uses −1 to signal an error. The builtin rebase converts these to +1 all over the place using !! (presumably because the in the scripted version an error was signalled by +1). This is confusing and clutters the code, we only need to convert the value when the function returns. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22grep: store grep_source buffer as constJeff King2-5/+8
Our grep_buffer() function takes a non-const buffer, which is confusing: we don't take ownership of nor write to the buffer. This mostly comes from the fact that the underlying grep_source struct in which we store the buffer uses non-const pointer. The memory pointed to by the struct is sometimes owned by us (for FILE or OID sources), and sometimes not (for BUF sources). Let's store it as const, which lets us err on the side of caution (i.e., the compiler will warn us if any of our code writes to or tries to free it). As a result, we must annotate the one place where we do free it by casting away the constness. But that's a small price to pay for the extra safety and clarity elsewhere (and indeed, it already had a comment explaining why GREP_SOURCE_BUF _didn't_ free it). And then we can mark grep_buffer() as taking a const buffer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22grep: mark "haystack" buffers as constJeff King1-26/+35
When we're grepping in a buffer, we don't need to modify it. So we can take "const char *" buffers, rather than "char *". This can avoid some awkward casts in our callers, and make our expectations more clear (we will not take ownership of the memory, nor will we ever write to it). These spots don't all necessarily have to be converted at the same time, but some of them are dependent on others, because we pass pointers-to-pointers in a few cases. And none of this should change any behavior, since we're just adding "const" qualifiers (and likewise, the compiler will let us know if we missed any spots). So it's relatively low-risk to just do this all at once. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22grep: stop modifying buffer in grep_source_1()Jeff King1-4/+1
We find the end of each matching line of a buffer, and then temporarily write a NUL to turn it into a regular C string. But we don't need to do so, because the only thing we do in the interim is pass the line and its length (via an "eol" pointer) to match_line(). And that function should only look at the bytes we passed it, whether it has a terminating NUL or not. We can drop this temporary write in order to simplify the code and make it easier to use const buffers in more of grep.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22grep: stop modifying buffer in show_line()Jeff King1-3/+0
When showing lines via grep (or looking for funcnames), we call show_line() on a multi-line buffer. It finds the end of line and marks it with a NUL. However, we don't need to do so, as the resulting line is only used along with its "eol" marker: - we pass both to next_match(), which takes care to look at only the bytes we specified - we pass the line to output_color() without its matching eol marker. However, we do use the "match" struct we got from next_match() to tell it how many bytes to look at (which can never exceed the string we passed it). So we can stop setting and restoring this NUL marker. That makes the code simpler, and will allow us to take a const buffer in a future patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22grep: stop modifying buffer in strip_timestampJeff King1-10/+3
When grepping for headers in commit objects, we receive individual lines (e.g., "author Name <email> 1234 -0000"), and then strip off the timestamp to do our match. We do so by writing a NUL byte over the whitespace separator, and then remembering to restore it later. We had to do it this way when this was added back in a4d7d2c6db (log --author/--committer: really match only with name part, 2008-09-04), because we fed the result directly to regexec(), which expects a NUL-terminated string. But since b7d36ffca0 (regex: use regexec_buf(), 2016-09-21), we have a function which can match part of a buffer. So instead of modifying the string, we can instead just move the "eol" pointer, and the rest of the code will do the right thing. This will let further patches mark more buffers as "const". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22builtin/multi-pack-index.c: disable top-level --[no-]progressTaylor Blau3-14/+35
In a similar spirit as the previous patch, let sub-commands which support showing or hiding a progress meter handle parsing the `--progress` or `--no-progress` option, but do not expose it as an option to the top-level `multi-pack-index` builtin. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20The seventh batchJunio C Hamano1-0/+52
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20Merge branch 'jk/t5562-racefix'Junio C Hamano1-8/+8
Test update. * jk/t5562-racefix: t5562: use alarm() to interrupt timed child-wait
2021-09-20Merge branch 'rs/no-mode-to-open-when-appending'Junio C Hamano1-1/+1
The "mode" word is useless in a call to open(2) that does not create a new file. Such a call in the files backend of the ref subsystem has been cleaned up. * rs/no-mode-to-open-when-appending: refs/files-backend: remove unused open mode parameter
2021-09-20Merge branch 'rs/setup-use-xopen-and-xdup'Junio C Hamano1-5/+3
Code clean-up. * rs/setup-use-xopen-and-xdup: setup: use xopen and xdup in sanitize_stdfds
2021-09-20Merge branch 'js/run-command-close-packs'Junio C Hamano10-27/+32
The run-command API has been updated so that the callers can easily ask the file descriptors open for packfiles to be closed immediately before spawning commands that may trigger auto-gc. * js/run-command-close-packs: Close object store closer to spawning child processes run_auto_maintenance(): implicitly close the object store run-command: offer to close the object store before running run-command: prettify the `RUN_COMMAND_*` flags pull: release packs before fetching commit-graph: when closing the graph, also release the slab
2021-09-20Merge branch 'ds/mergies-with-sparse-index'Junio C Hamano8-10/+129
Various mergy operations have been prepared to work efficiently with the sparse index. * ds/mergies-with-sparse-index: sparse-index: integrate with cherry-pick and rebase sequencer: ensure full index if not ORT strategy t1092: add cherry-pick, rebase tests merge-ort: expand only for out-of-cone conflicts merge: make sparse-aware with ORT diff: ignore sparse paths in diffstat
2021-09-20Merge branch 'ds/sparse-index-ignored-files'Junio C Hamano12-62/+312
In cone mode, the sparse-index code path learned to remove ignored files (like build artifacts) outside the sparse cone, allowing the entire directory outside the sparse cone to be removed, which is especially useful when the sparse patterns change. * ds/sparse-index-ignored-files: sparse-checkout: clear tracked sparse dirs sparse-index: add SPARSE_INDEX_MEMORY_ONLY flag attr: be careful about sparse directories sparse-checkout: create helper methods sparse-index: use WRITE_TREE_MISSING_OK sparse-index: silently return when cache tree fails unpack-trees: fix nested sparse-dir search sparse-index: silently return when not using cone-mode patterns t7519: rewrite sparse index test
2021-09-20Merge branch 'ar/submodule-run-update-procedure'Junio C Hamano2-72/+289
Reimplementation of parts of "git submodule" in C continues. * ar/submodule-run-update-procedure: submodule--helper: run update procedures from C
2021-09-20Merge branch 'ab/make-tags-cleanup'Junio C Hamano1-13/+19
Build clean-up for "make tags" and friends. * ab/make-tags-cleanup: Makefile: normalize clobbering & xargs for tags targets Makefile: remove "cscope.out", not "cscope*" in cscope.out target Makefile: don't use "FORCE" for tags targets Makefile: add QUIET_GEN to "cscope" target Makefile: move ".PHONY: cscope" near its target
2021-09-20Merge branch 'ab/serve-cleanup'Junio C Hamano20-128/+298
Code clean-up around "git serve". * ab/serve-cleanup: upload-pack: document and rename --advertise-refs serve.[ch]: remove "serve_options", split up --advertise-refs code {upload,receive}-pack tests: add --advertise-refs tests serve.c: move version line to advertise_capabilities() serve: move transfer.advertiseSID check into session_id_advertise() serve.[ch]: don't pass "struct strvec *keys" to commands serve: use designated initializers transport: use designated initializers transport: rename "fetch" in transport_vtable to "fetch_refs" serve: mark has_capability() as static
2021-09-20Merge branch 'ar/submodule-add-more'Junio C Hamano5-355/+291
More parts of "git submodule add" has been rewritten in C. * ar/submodule-add-more: submodule--helper: rename compute_submodule_clone_url() submodule--helper: remove resolve-relative-url subcommand submodule--helper: remove add-config subcommand submodule--helper: remove add-clone subcommand submodule--helper: convert the bulk of cmd_add() to C dir: libify and export helper functions from clone.c submodule--helper: remove repeated code in sync_submodule() submodule--helper: refactor resolve_relative_url() helper submodule--helper: add options for compute_submodule_clone_url()
2021-09-20Merge branch 'ar/submodule-add-config'Junio C Hamano3-27/+135
Large part of "git submodule add" gets rewritten in C. * ar/submodule-add-config: submodule--helper: introduce add-config subcommand
2021-09-20Merge branch 'ab/unbundle-progress'Junio C Hamano7-11/+46
Add progress display to "git bundle unbundle". * ab/unbundle-progress: bundle: show progress on "unbundle" index-pack: add --progress-title option bundle API: change "flags" to be "extra_index_pack_args" bundle API: start writing API documentation
2021-09-20Merge branch 'tb/pack-finalize-ordering'Junio C Hamano6-67/+96
The order in which various files that make up a single (conceptual) packfile has been reevaluated and straightened up. This matters in correctness, as an incomplete set of files must not be shown to a running Git. * tb/pack-finalize-ordering: pack-objects: rename .idx files into place after .bitmap files pack-write: split up finish_tmp_packfile() function builtin/index-pack.c: move `.idx` files into place last index-pack: refactor renaming in final() builtin/repack.c: move `.idx` files into place last pack-write.c: rename `.idx` files after `*.rev` pack-write: refactor renaming in finish_tmp_packfile() bulk-checkin.c: store checksum directly pack.h: line-wrap the definition of finish_tmp_packfile()
2021-09-20Merge branch 'cb/pedantic-build-for-developers'Junio C Hamano6-58/+15
Update the build procedure to use the "-pedantic" build when DEVELOPER makefile macro is in effect. * cb/pedantic-build-for-developers: developer: enable pedantic by default win32: allow building with pedantic mode enabled gettext: remove optional non-standard parens in N_() definition
2021-09-20Merge branch 'ab/progress-users-adjust-counters'Junio C Hamano2-8/+6
The code to show progress indicator in a few code paths did not cover between 0-100%, which has been corrected. * ab/progress-users-adjust-counters: entry: show finer-grained counter in "Filtering content" progress line commit-graph: fix bogus counter in "Scanning merged commits" progress line
2021-09-20Merge branch 'dt/submodule-diff-fixes'Junio C Hamano2-9/+164
"git diff --submodule=diff" showed failure from run_command() when trying to run diff inside a submodule, when the user manually removes the submodule directory. * dt/submodule-diff-fixes: diff --submodule=diff: don't print failure message twice diff --submodule=diff: do not fail on ever-initialied deleted submodules t4060: remove unused variable
2021-09-20Merge branch 'jv/pkt-line-batch'Junio C Hamano6-5/+72
Reduce number of write(2) system calls while sending the ref advertisement. * jv/pkt-line-batch: upload-pack: use stdio in send_ref callbacks pkt-line: add stdio packet write functions
2021-09-20Merge branch 'lh/systemd-timers'Junio C Hamano5-80/+694
"git maintenance" scheduler learned to use systemd timers as a possible backend. * lh/systemd-timers: maintenance: add support for systemd timers on Linux maintenance: `git maintenance run` learned `--scheduler=<scheduler>` cache.h: Introduce a generic "xdg_config_home_for(…)" function
2021-09-20Merge branch 'ab/tr2-leaks-and-fixes'Junio C Hamano2-24/+146
The tracing of process ancestry information has been enhanced. * ab/tr2-leaks-and-fixes: tr2: log N parent process names on Linux tr2: do compiler enum check in trace2_collect_process_info() tr2: leave the parent list empty upon failure & don't leak memory tr2: stop leaking "thread_name" memory tr2: clarify TRACE2_PROCESS_INFO_EXIT comment under Linux tr2: remove NEEDSWORK comment for "non-procfs" implementations
2021-09-20Merge branch 'jt/grep-wo-submodule-odb-as-alternate'Junio C Hamano11-55/+161
The code to make "git grep" recurse into submodules has been updated to migrate away from the "add submodule's object store as an alternate object store" mechanism (which is suboptimal). * jt/grep-wo-submodule-odb-as-alternate: t7814: show lack of alternate ODB-adding submodule-config: pass repo upon blob config read grep: add repository to OID grep sources grep: allocate subrepos on heap grep: read submodule entry with explicit repo grep: typesafe versions of grep_source_init grep: use submodule-ODB-as-alternate lazy-addition submodule: lazily add submodule ODBs as alternates
2021-09-20Merge branch 'tb/multi-pack-bitmaps'Junio C Hamano28-464/+1675
The reachability bitmap file used to be generated only for a single pack, but now we've learned to generate bitmaps for history that span across multiple packfiles. * tb/multi-pack-bitmaps: (29 commits) pack-bitmap: drop bitmap_index argument from try_partial_reuse() pack-bitmap: drop repository argument from prepare_midx_bitmap_git() p5326: perf tests for MIDX bitmaps p5310: extract full and partial bitmap tests midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' t7700: update to work with MIDX bitmap test knob t5319: don't write MIDX bitmaps in t5319 t5310: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP t5326: test multi-pack bitmap behavior t/helper/test-read-midx.c: add --checksum mode t5310: move some tests to lib-bitmap.sh pack-bitmap: write multi-pack bitmaps pack-bitmap: read multi-pack bitmaps pack-bitmap.c: avoid redundant calls to try_partial_reuse pack-bitmap.c: introduce 'bitmap_is_preferred_refname()' pack-bitmap.c: introduce 'nth_bitmap_object_oid()' pack-bitmap.c: introduce 'bitmap_num_objects()' midx: avoid opening multiple MIDXs when writing midx: close linked MIDXs, avoid leaking memory ...
2021-09-20Merge branch 'ps/fetch-optim'Junio C Hamano6-61/+67
Optimize code that handles large number of refs in the "git fetch" code path. * ps/fetch-optim: fetch: avoid second connectivity check if we already have all objects fetch: merge fetching and consuming refs fetch: refactor fetch refs to be more extendable fetch-pack: optimize loading of refs via commit graph connected: refactor iterator to return next object ID directly fetch: avoid unpacking headers in object existence check fetch: speed up lookup of want refs via commit-graph
2021-09-20clone: handle unborn branch in bare reposJeff King2-15/+29
When cloning a repository with an unborn HEAD, we'll set the local HEAD to match it only if the local repository is non-bare. This is inconsistent with all other combinations: remote HEAD | local repo | local HEAD ----------------------------------------------- points to commit | non-bare | same as remote points to commit | bare | same as remote unborn | non-bare | same as remote unborn | bare | local default So I don't think this is some clever or subtle behavior, but just a bug in 4f37d45706 (clone: respect remote unborn HEAD, 2021-02-05). And it's easy to see how we ended up there. Before that commit, the code to set up the HEAD for an empty repo was guarded by "if (!option_bare)". That's because the only thing it did was call install_branch_config(), and we don't want to do so for a bare repository (unborn HEAD or not). That commit put the handling of unborn HEADs into the same block, since those also need to call install_branch_config(). But the unborn case has an additional side effect of calling create_symref(), and we want that to happen whether we are bare or not. This patch just pulls all of the "figure out the default branch" code out of the "!option_bare" block. Only the actual config installation is kept there. Note that this does mean we might allocate "ref" and not use it (if the remote is empty but did not advertise an unborn HEAD). But that's not really a big deal since this isn't a hot code path, and it keeps the code simple. The alternative would be handling unborn_head_target separately, but that gets confusing since its memory ownership is tangled up with the "ref" variable. There's just one new test, for the case we're fixing. The other ones in the table are handled elsewhere (the unborn non-bare case just above, and the actually-born cases in t5601, t5606, and t5609, as they do not require v2's "unborn" protocol extension). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20Merge branch 'ab/retire-option-argument' into da/difftoolJunio C Hamano6-52/+26
* ab/retire-option-argument: parse-options API: remove OPTION_ARGUMENT feature difftool: use run_command() API in run_file_diff() difftool: prepare "diff" cmdline in cmd_difftool() difftool: prepare "struct child_process" in cmd_difftool()
2021-09-20merge-ort: fix completely wrong commentElijah Newren1-1/+1
Not sure what happened, but the comment is describing code elsewhere in the file. Fix the comment to actually discuss the code that follows. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20trace2.h: fix trivial comment typoElijah Newren1-1/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20Merge branch 'en/am-abort-fix' into en/removing-untracked-fixesJunio C Hamano3-1/+43
* en/am-abort-fix: am: fix incorrect exit status on am fail to abort t4151: add a few am --abort tests git-am.txt: clarify --abort behavior
2021-09-20builtin/commit-graph.c: don't accept common --[no-]progressTaylor Blau1-2/+4
In 84e4484f12 (commit-graph: use parse_options_concat(), 2021-08-23) we unified common options of commit-graph's subcommands into a single "common_opts" array. But 84e4484f12 introduced a behavior change which is to accept the "--[no-]progress" option before any sub-commands, e.g., git commit-graph --progress write ... Prior to that commit, the above would error out with "unknown option". There are two issues with this behavior change. First is that the top-level --[no-]progress is not always respected. This is because isatty(2) is performed in the sub-commands, which unconditionally overwrites any --[no-]progress that was given at the top-level. But the second issue is that the existing sub-commands of commit-graph only happen to both have a sensible interpretation of what `--progress` or `--no-progress` means. If we ever added a sub-command which didn't have a notion of progress, we would be forced to ignore the top-level `--[no-]progress` altogether. Since we haven't released a version of Git that supports --[no-]progress as a top-level option for `git commit-graph`, let's remove it. Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20Document `rebase.forkpoint` in rebase man pageWesley Schwengle1-1/+2
The configuration option `rebase.forkpoint' is only mentioned in the man page of git-config(1). Since it is a configuration for rebase, mention it in the documentation of rebase at the --fork-point/--no-fork-point section. This will help users set a preferred default for their workflow. Signed-off-by: Wesley Schwengle <wesley@opperschaap.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20t/helper/simple-ipc: convert test-simple-ipc to use start_bg_commandJeff Hostetler1-156/+43
Convert test helper to use `start_bg_command()` when spawning a server daemon in the background rather than blocks of platform-specific code. Also, while here, remove _() translation around error messages since this is a test helper and not Git code. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20run-command: create start_bg_commandJeff Hostetler2-0/+186
Create a variation of `run_command()` and `start_command()` to launch a command into the background and optionally wait for it to become "ready" before returning. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20simple-ipc/ipc-win32: add Windows ACL to named pipeJeff Hostetler1-11/+129
Set an ACL on the named pipe to allow the well-known group EVERYONE to read and write to the IPC server's named pipe. In the event that the daemon was started with elevation, allow non-elevated clients to communicate with the daemon. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20simple-ipc/ipc-win32: add trace2 debuggingJeff Hostetler1-1/+24
Create "ipc-debug" category events to log unexpected errors when creating Simple-IPC connections. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20simple-ipc: move definition of ipc_active_state outside of ifdefCarlo Marcelo Arenas Belón1-7/+7
Move the declartion of the `enum ipc_active_state` type outside of the SUPPORTS_SIMPLE_IPC ifdef. A later commit will introduce the `fsmonitor_ipc__*()` API and stub in a "mock" implementation that requires this enum in some function signatures. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20simple-ipc: preparations for supporting binary messages.Jeff Hostetler4-23/+46
Add `command_len` argument to the Simple IPC API. In my original Simple IPC API, I assumed that the request would always be a null-terminated string of text characters. The `command` argument was just a `const char *`. I found a caller that would like to pass a binary command to the daemon, so I am amending the Simple IPC API to receive `const char *command, size_t command_len` arguments. I considered changing the `command` argument to be a `void *`, but the IPC layer simply passes it to the pkt-line layer which takes a `const char *`, so to avoid confusion I left it as is. Note, the response side has always been a `struct strbuf` which includes the buffer and length, so we already support returning a binary answer. (Yes, it feels a little weird returning a binary buffer in a `strbuf`, but it works.) Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20trace2: add trace2_child_ready() to report on background childrenJeff Hostetler7-0/+152
Create "child_ready" event to capture the state of a child process created in the background. When a child command is started a "child_start" event is generated in the Trace2 log. For normal synchronous children, a "child_exit" event is later generated when the child exits or is terminated. The two events include information, such as the "child_id" and "pid", to allow post analysis to match-up the command line and exit status. When a child is started in the background (and may outlive the parent process), it is not possible for the parent to emit a "child_exit" event. Create a new "child_ready" event to indicate whether the child was successfully started. Also include the "child_id" and "pid" to allow similar post processing. This will be used in a later commit with the new "start_bg_command()". Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-17unicode: update the width tables to Unicode 14Carlo Marcelo Arenas Belón1-15/+29
Released[0] after a long beta period and including several additional zero/double width characters. [0] https://home.unicode.org/announcing-the-unicode-standard-version-14-0/ Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-17t5326: test propagating hashcache valuesTaylor Blau1-0/+30
Now that we both can propagate values from the hashcache, and respect the configuration to enable the hashcache at all, test that both of these function correctly by hardening their behavior with a test. Like the hash-cache in classic single-pack bitmaps, this helps more proportionally the more up-to-date your bitmap coverage is. When our bitmap coverage is out-of-date with the ref tips, we spend more time proportionally traversing, and all of that traversal gets the name-hash filled in. But for the up-to-date bitmaps, this helps quite a bit. These numbers are on git.git, with `pack.threads=1` to help see the difference reflected in the overall runtime. Test origin/tb/multi-pack-bitmaps HEAD ------------------------------------------------------------------------------------- 5326.4: simulated clone 1.87(1.80+0.07) 1.46(1.42+0.03) -21.9% 5326.5: simulated fetch 2.66(2.61+0.04) 1.47(1.43+0.04) -44.7% 5326.6: pack to file (bitmap) 2.74(2.62+0.12) 1.89(1.82+0.07) -31.0% Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-17p5326: generate pack bitmaps before writing the MIDX bitmapTaylor Blau1-1/+8
To help test the performance of permuting the contents of the hash-cache when generating a MIDX bitmap, we need a bitmap which has its hash-cache populated. And since multi-pack bitmaps don't add *new* values to the hash-cache, we have to rely on a single-pack bitmap to generate those values for us. Therefore, generate a pack bitmap before the MIDX one in order to ensure that the MIDX bitmap has entries in its hash-cache. Since we don't want to time generating the pack bitmap, move that to a non-perf test run before we try to generate the MIDX bitmap. Likewise, get rid of the pack bitmap afterwords, to make certain that we are not accidentally using it in the performance tests run later on. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-16Documentation: cleanup git-cvsserverCarlo Marcelo Arenas Belón1-8/+9
Fix a few typos and alignment issues, and while at it update the example hashes to show most of the ones available in recent crypt(3). Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>