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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Sparse Index] Integrate with
git status
#374[Sparse Index] Integrate with
git status
#374Changes from all commits
2a4a725
f5bae86
d965669
44a9402
701ac0e
587333f
6fc898a
b676ef4
d693f00
ed11cfc
48fd25a
3499105
60a6706
76bd8ec
a1a570a
093a832
722e7cd
9edbebf
0fda21d
610518c
320586f
ddaebb7
44bfb50
0c20b94
f462956
87a3a29
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would
.
make sense here instead of-
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason having a filename as
.
seems stranger to me than-
. Perhaps_
would seem less odd?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I talked with @dscho offline here and here is the conclusion:
path/to/directory/.
is semantically identical topath/to/directory
, so.
is a natural option here./.
. While it is dumb enough to ignore that, we would be adding an expectation that it remains dumb and otherwise doesn't check that the input path is a valid name for a file.The conclusion is that this is a clever idea, but perhaps too clever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure there is a correct answer here. But it makes me want to say that we want to treat the ce's as a {type,path} tuple with an accessor and all that and get away from the pattern of just iterating over a dumb list of strings (that all callers know is a dumb list of strings).
Is there existing code to detect file -vs- symlink collisions? or file -vs- submodule collisions? How are they handled?
I mean we're adding the concept of (sparse) directory nodes into the index; it would be nice if they collided the same way. (I'm not trying to cause problems, just asking dumb questions.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative would be to map the old extension data (which is essentially a compressed version of the
fsmonitor_dirty
bitmap, which we should be able to map relatively easily by iterating over the full and the sparse index simultaneously).I do not suggest to implement this here, but maybe mention it as a potential future improvement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you recommending a translation of the old bitmap into a new bitmap based on the new path positions? Yes, that would work, but I don't think it is worth pursuing much at all. We are better off investing in the sparse-index work such that we only change the sparse directory entries during
git sparse-checkout set
, which is rare and likely is on a clean working directory.