[pull] master from git:master#58
Merged
pull[bot] merged 11 commits intodevnw-forks:masterfrom Jul 25, 2024
Merged
Conversation
Git 2.45.0 included the change b7d6f23 (midx-write.c: use `--stdin-packs` when repacking, 2024-04-01) which caused the 'git multi-pack-index repack' command to use 'git pack-objects --stdin-packs' instead of listing the objects to repack. While this change was motivated by efficient cross-process communication and the ability to improve delta compression, it breaks a fundamental function of the 'incremental-repack' task that is enabled by default in Scalar clones or Git repositories that run 'git maintenance start'. The 'incremental-repack' task performs a two-step process of the 'expire' and 'repack' subcommands of the 'git multi-pack-index' builtin. The 'expire' command removes any pack-files listed in the multi-pack-index but without any referenced objects. The 'repack' task then finds a batch of pack-files to repack and sends their objects to 'git pack-objects'. Both the pack-files chosen for the batch and the objects chosen to repack are based on the ones that the multi-pack-index references. Objects that appear in a pack-file but have a duplicate copy in a newer pack-file are not considered in this case. Since the multi-pack-index references only the newest copy of an object, this allows the next 'incremental-repack' task to remove the pack-files in the next 'expire' task. This delay is intentional due to how Windows handles may block deletion of files with open read handles. However, the mentioned commit changed this behavior to divorce the set of objects referenced by the multi-pack-index and instead use a set of "included" and "excluded" pack-files in the 'git pack-objects' builtin. When a pack-file is selected as "included", only the objects it contains but are not in any "excluded" pack-files are considered for repacking. This has led to client repositories failing to remove old pack-files as they still have some referenced objects. This grows over time until the point that Git is trying to repack the same pack-files over and over. For now, create a test case that demonstrates the expected behavior, but also fails in its final line. The setup here it attempting to recreate a typical situation for a repository that uses a blobless partial clone. There would be a large initial pack-file from the clone that is never selected in the 'repack' batch. There are other pack-files that have a combination of new objects from incremental fetches and possibly blobs that are not connected to those incremental fetches; these blobs could be filled in from commands like 'git checkout' or 'git blame'. The pack-files also have some overlap on purpose so test-1 has some duplicates in test-2 and test-2 has some duplicates in test-3. At the end of the test, the test-2 pack-file still exists though it should have been expired. This test will pass when reverting the offending commit. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts b7d6f23 (midx-write.c: use `--stdin-packs` when repacking, 2024-04-01) and then marks the test created in the previous change as passing. The fundamental issue with the reverted change is that the focus on pack-files separates the object selection from how the multi-pack-index selects a single pack-file for an object ID with multiple copies among the tracked pack-files. The change was made with the intention of improving delta compression in the resulting pack-file, but that can be resolved with the existing object list mechanism. There are other potential pitfalls of doing an object walk at this time if the repository is a blobless partial clone, and that will require additional testing on top of the one that changes here. Signed-off-by: Derrick Stolee <stolee@gmail.com> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc.py does not have the concept of generalized roles, whereas
asciidoctor interprets [foo]`blah` as blah with role foo in the
synopsis, making in effect foo disappear in the output. Note that
square brackets not directly followed by an inline markup do not
define a role, which is why we do not have the issue on other parts of
the documentation.
In order to get a consistant result across asciidoctor and
asciidoc.py, the hack is to use the {empty} entity
to split the bracket part from the inline format part.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 76880f0 (doc: git-clone: apply new documentation formatting guidelines, 2024-03-29), the synopsis of `git clone`'s manual page is rendered differently than before; Its parent commit did the same for `git init`. The result looks quite nice. When rendered with AsciiDoc, that is. When rendered using AsciiDoctor and displayed in a graphical web browser such as Firefox, Chrome, Edge, etc, the result is quite unpleasant to my eye, reading something like this: SYNOPSIS git clone [ --template= <template-directory>] [ -l ] [ -s ] [ --no-hardlinks ] [ -q ] [ [... continuing like this ...] The reason is that AsciiDoctor's default style sheet contains this (see https://github.com/asciidoctor/asciidoctor/blob/854923b15533/src/stylesheets/asciidoctor.css#L519-L521 for context): pre > code { display: block; } It is this `display: block` that forces the parts that are enclosed in `<code>` tags (such as the `git clone` or the `--template=` part) to be rendered on their own line. Side note: This seems not to affect console web browsers like `lynx` or `w3m`, most likely because most style sheet directions cannot be respected in text terminals and therefore they seem to punt on style sheets altogether. To fix this, let's apply the method recommended by AsciiDoctor in https://docs.asciidoctor.org/asciidoctor/latest/html-backend/default-stylesheet/#customize-docinfo to partially override AsciiDoctor's default style sheet so that the `<code>` sections of the synopsis are no longer each rendered on their own, individual lines. This fixes git-for-windows#5063. Even on the Git home page, where AsciiDoctor's default stylesheet is _not_ used, this change resulted in some unpleasant rendering where not only the font is changed for the `<code>` sections of the synopsis, but padding and a different background color make the visual impression quite uneven. This has been addressed in the meantime, via git/git-scm.com@a492d0565512. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was reported that t1460-refs-migrate.sh fails when using Cygwin with
errors like the following:
error: could not link file '.git/ref_migration.sr9pEF/reftable' to '.git/reftable': Permission denied
As some debugging surfaced, the root cause of this is that some files of
the newly-initialized ref store are still open when the target format is
the "reftable" format, and Cygwin refuses to rename open files.
Fix this issue by closing the new ref store before renaming its files
into place. This is a slight change in behaviour compared to before,
where we kept the new ref store open and then updated the repository's
ref store to point to it.
While we could re-open the new ref store after we have moved files
around, this is ultimately unnecessary. We know that the only user of
`repo_migrate_ref_storage_format()` is the git-refs(1) command, and it
won't access the ref store after it has been migrated anyway. So
reinitializing the ref store would be a waste of time. Regardless of
that it is still sensible to leave the repository in a consistent state.
But instead of reinitializing the ref store, we can simply unset the
repo's ref store altogether and let `get_main_ref_store()` lazily
initialize the new ref store as required.
Reported-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous step introduced docinfo.html to be used to tweak the CSS used by the asciidoctor, that by default renders <code> inside <pre> as a block element, breaking the SYNOPSIS section of a few pages that adopted a new convention we use since Git 2.45. But in this project, HTML files are all generated. We do not force any human to write HTML by hand, which is an unusual and cruel punishment. "*.html" is in the .gitignore file, and "make clean" removes them. Having a tracked .html file makes "make clean" make the tree dirty by removing the tracked docinfo.html file. Let's do an obvious, minimum and stupid workaround to generate that file at runtime instead. The mark-up is being rethought in a major way for the next development cycle, and the CSS workaround we added in the previous step may have to adjusted, possibly in a large way, anyway. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Repacking a repository with multi-pack index started making stupid pack selections in Git 2.45, which has been corrected. * ds/midx-write-repack-fix: midx-write: revert use of --stdin-packs t5319: add failing test case for repack/expire
Fix documentation mark-up regression in 2.45. * ja/doc-markup-updates-fix: doc: git-clone fix discrepancy between asciidoc and asciidoctor
Work around asciidoctor's css that renders `monospace` material in the SYNOPSIS section of manual pages as block elements. * js/doc-markup-updates-fix: Doc: fix Asciidoctor css workaround asciidoctor: fix `synopsis` rendering
Hotfix for a topic already in -rc. * ps/ref-storage-migration-fix: refs: fix format migration on Cygwin
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )