Repository navigation
Conversation
When a fork's whole patch did not undo in the directory, each changed file was checked on its own: a `git diff` and a `git apply --check` for each. A fork with an upstream pull in it changes a thousand files, and listing the forks of turso took over ten minutes. Git checks every file's changes in one `git apply --reverse --check --verbose`, saying which file it is checking before any error about it, so the files that do not undo are counted from one run, without reading their paths back from what git says.
Every fork's files are clones of its base's, with new inodes and change times, so git hashed every file of every fork and base again: a few seconds each, for 4,500 files in turso. Git now compares only a file's size and modification time, which clones keep. It compares only the whole seconds of the time then, so a file whose time differs from the one the index was made from only within the second is hashed again first, comparing all its stat. It stays in the index, so that git does not ignore it.
The list was printed only once every fork had been looked into, after seconds with nothing to show. The header is printed at once, and each fork as soon as it is looked into, in the order they were made, with the columns as wide as the forks' paths, known before any is looked into, and the longest age.
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.
fsfork -lin a directory with 21 forks of turso took over ten minutes, with nothing printed until the end. It now takes about 20 seconds, and prints the header at once and each fork as soon as it is looked into:One
git applyfor all of a fork's filesWhen a fork's whole patch did not undo in the directory, each changed file was checked on its own, with a
git diffand agit apply --checkeach. Forks with an upstream pull in them change hundreds or thousands of files: turso.maint alone took about two minutes.Git checks every file in one
git apply --reverse --check --verbose, saying which file it is checking before any error about it, so the files that do not undo are counted from one run. The counts are the same as checking each file on its own, as checked on turso.7 and turso.rls.Hashing again only the files that changed
A fork's files are clones of its base's, with new inodes and change times, so git hashed all 4,500 files of every fork and base again: a few seconds each.
Git now compares only a file's size and modification time, which clones keep. It compares only whole seconds then, which missed a file changed within the same second to the same size, as the fsdiff tests do. So a file whose time differs from the one the index was made from only within the second is hashed again first, comparing all its stat, staying in the index so that git does not ignore it. This makes
fsdifffaster too.Each fork as soon as it is looked into
The forks are listed in the order they were made, rather than those left alone longest first, as sorting them would mean waiting for all.
--prunestill looks into all before removing any.Not done
Every run still hashes every base again, though bases never change: about two thirds of what is left. A cache that outlives the run, of each base's index and tree, would take that away.