Sparse Index: integrate with git show
#470
Merged
Conversation
This file contains 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
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho
approved these changes
Nov 29, 2021
vdye
approved these changes
Nov 29, 2021
Comment on lines
+1132
to
+1135
| # Asking "git show" for directories in the index | ||
| # does not work as implemented. The error message is | ||
| # different for a full checkout and a sparse checkout | ||
| # when the directory is outside of the cone. |
There was a problem hiding this comment.
Probably not necessary for now, but I'm guessing this should be fixed before submitting upstream? Most likely aligning the behavior of 'full-checkout', 'sparse-checkout', and 'sparse-index' either with an error or by "fixing" it in the non-sparse index cases.
There was a problem hiding this comment.
We definitely have time to think about it since the stuff currently sent upstream is taking a while to merge down. I'm personally torn between sending this as-is and asking "Should we align these behaviors?" versus doing the change in the same series and asking "Should we include patch X?"
I will think on this.
ldennington
reviewed
Dec 2, 2021
There was a problem hiding this comment.
This looks great ⭐ ! I think either of the solutions you proposed to @vdye's feedback would be all right. I'm also kinda surprised we're seeing significant usage of this in Office, but I imagine your guess that there's an automated process running this builtin is probably correct.
| test_must_fail git -C sparse-checkout show :folder1/ && | ||
|
|
||
| # The sparse index actually has "folder1" inside, so | ||
| # "git show :folder/" succeeds when it did not before. |
There was a problem hiding this comment.
Suggested change
| # "git show :folder/" succeeds when it did not before. | |
| # "git show :folder1/" succeeds when it did not before. |
1 task
The 'git show' command can take an input to request the state of an object in the index. This can lead to parsing the index in order to load a specific file entry. Without the change presented here, a sparse index would expand to a full one, taking much longer than usual to access a simple file. There is one behavioral change that happens here, though: we now can find a sparse directory entry within the index! Commands that previously failed because we could not find an entry in the worktree or index now succeed because we _do_ find an entry in the index. There might be more work to do to make other situations succeed when looking for an indexed tree, perhaps by looking at or updating the cache-tree extension as needed. These situations include having a full index or asking for a directory that is within the sparse-checkout cone (and hence is not a sparse directory entry in the index). Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee
force-pushed
the
sparse-index/show-vfs
branch
from
4f45ee9
to
3a86715
Compare
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 12, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 19, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 20, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 25, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
ldennington
pushed a commit
to ldennington/git
that referenced
this pull request
Jan 25, 2022
…how` As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
dscho
pushed a commit
that referenced
this pull request
Feb 1, 2022
As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
dscho
pushed a commit
that referenced
this pull request
Jun 17, 2022
As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
dscho
pushed a commit
that referenced
this pull request
Jun 17, 2022
As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
dscho
pushed a commit
that referenced
this pull request
Jun 17, 2022
As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example, `git mv` is used much less frequently.) Since the index expansion only happens when using `git show :<path>` to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50). The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.
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.
As we roll out the sparse index feature, here is a command that I see being used more frequently than other non-integrated commands. (For example,
git mvis used much less frequently.)Since the index expansion only happens when using
git show :<path>to indicate that we are looking for a cached value, this is very likely being used by a tool and not directly by users. However, the performance slowdown is around 10x (0.4s to 4.1s at p50).The change here is simple, and we can catch up the performance in the next release. There is a slightly odd behavior change when asking for a directory that now "works" but did not work at all before. See the test change in the second commit for details.