Repository navigation
Conversation
Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
ReFS can share file extents through FSCTL_DUPLICATE_EXTENTS_TO_FILE, but callers should not need platform-specific logic. Provide a compatibility primitive that reports unsupported elsewhere, allowing callers to use block cloning as an opportunistic optimization with an ordinary write as fallback. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Linked worktrees can contain many identical large files even though they already share the object database. On filesystems that advertise block refcounting, pass the current worktree to the checkout and clone only regular, unconverted files whose contents hash to the requested blob. Any unsupported operation or clone failure falls back silently to the normal checkout path. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Document the alignment and chunk-size requirements, and restore the exact destination length after cloning the rounded final range. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Explain why the destination is sized both before and after cloning the aligned extent range. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Keep converted and non-regular entries eligible for parallel checkout because they cannot use the block-clone path. Document the helper fallback contract and source-path lifetime. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
compat: add copy-on-write file support Linked worktrees can share the storage backing identical files on file systems that provide copy-on-write copies. Callers should be able to request that optimization without knowing the platform-specific mechanism or treating lack of support as an error. Provide file_copy_on_write() on Windows and a minimal ENOSYS fallback elsewhere. ReFS requires aligned ranges smaller than 4 GiB, so use 4 GiB minus 64 KiB for full ranges and issue one rounded request for the tail, trying the two valid ReFS cluster sizes. These are alternative tail alignments, not 64 KiB-sized chunks. Truncating afterward removes only the alignment padding. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Co-authored-by: dscho <127790+dscho@users.noreply.github.com> Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
compat: add copy-on-write file support Linked worktrees can share the storage backing identical files on file systems that provide copy-on-write copies. Callers should be able to request that optimization without knowing the platform-specific mechanism or treating lack of support as an error. Provide file_copy_on_write() on Windows and a minimal ENOSYS fallback elsewhere. ReFS requires aligned ranges smaller than 4 GiB, so use 4 GiB minus 64 KiB for full ranges and issue one rounded request for the tail, trying the two valid ReFS cluster sizes. These are alternative tail alignments, not 64 KiB-sized chunks. Truncating afterward removes only the alignment padding. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com> Signed-off-by: GitHub <noreply@github.com>
worktree: copy unchanged files on write Creating a linked worktree normally materializes another physical copy of every checked-out file. File systems with copy-on-write support can avoid that cost, but only when an existing working-tree file is known to represent exactly the target index entry. For a non-bare source, refresh and write its index after recording the current wall-clock time. The reset child loads that index and considers non-sparse entries whose object IDs and conversion attributes match. It requires the opened file stat data to match the refreshed index and predate the recorded time, both before and after copying, which retains Git\047s racy-index protection without hashing converted or Git LFS content. Keep the decision in reset and honor worktree.copyOnWrite=false so users can disable the optimization if a platform implementation proves problematic. Unsupported operations and all validation failures retain the normal checkout path. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Expose the primitive through test-tool so tests can establish a runtime prerequisite by performing a real copy-on-write operation. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Exercise the optimization only after a real copy-on-write probe succeeds. Verify Trace2 records successful copies for clean raw and CRLF-converted files, excludes dirty raw and converted files, and honors the configuration opt-out. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Document the copy-on-write optimization and its opt-out. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Avoid refreshing and writing the source index on platforms where the copy-on-write primitive is unavailable. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Document the lifetime of the caller-owned copy source passed through unpack_trees_options. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Keep the configuration opt-out separate from capability and metadata validation so the successful lookup semantics are explicit. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
State explicitly that both the copy source and its index remain caller-owned for the duration of unpacking. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Resolve the source index entry and its conversion attributes once before deciding whether checkout can run in parallel, then carry that entry into the synchronous copy-on-write path. Signed-off-by: GitHub <noreply@github.com> Co-authored-by: GPT-5.4 <noreply@openai.com> Co-authored-by: dscho <127790+dscho@users.noreply.github.com>
Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…source of cloning properly Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…t expected to be cloned even it those files are clean, that is more conservative approach. Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…with zeros Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…ailed clone attempt on NTFS Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…ot needed because proper file size was set on file creation. Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
… often use case Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…kipped if worktree is created in empty folder Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
…segment is not cloned because cloning not aligned segment is slow, it is rather copied from source. Fixed and optimized check for source-clone for git repositories with autocrlf=false where cloning was not executed at all (facebook/react, microsoft/vscode, kubernetes/kubernetes). Signed-off-by: Tomas Kubes <kubes.tomas@gmail.com>
This was referenced Oct 9, 2026
qub1n
changed the title
This branch has not been deployed
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
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.
Hi there,
I spent some time with testing, fixing and optimizing ReFS support for git work tree implementation originally created with copilot and now I came to the point in which it works quite good.
Correctness was tested on artificial and real git repositories.
Overall the cloning is slower for small files, so I chosen threshold of files > 160KiB for which cloning happen on ReFS.
The last unaligned segment is not cloned, but rather copied due to performance.
I was comparing runs on two VHDX disk one with ReFS and second with NTFS on my laptop Acer Nitro V16. It is faster in almost all testing cases compare to original implementation with either NTFS or ReFS and in the same time it brings space savings around 30%, space saving was counted from occupied blocks on disk.
In common repositories threshold of 160Kb clone very small amount of files (in count), but good portion of size of repository. Lower threshold would mean slightly slower creating of work tree, but much bigger space saving.
Git-ReFS-Correctness-Report.pdf