Skip to content
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

Merged
Changes from 1 commit
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
2a4a725
sparse-index: skip indexes with unmerged entries
derrickstolee Apr 29, 2021
f5bae86
sparse-index: include EXTENDED flag when expanding
derrickstolee May 4, 2021
d965669
t1092: replace incorrect 'echo' with 'cat'
derrickstolee May 26, 2021
44a9402
t1092: expand repository data shape
derrickstolee May 14, 2021
701ac0e
t1092: add tests for status/add and sparse files
derrickstolee Apr 12, 2021
587333f
unpack-trees: preserve cache_bottom
derrickstolee Apr 21, 2021
6fc898a
unpack-trees: compare sparse directories correctly
derrickstolee Apr 21, 2021
b676ef4
unpack-trees: unpack sparse directory entries
derrickstolee May 27, 2021
d693f00
dir.c: accept a directory as part of cone-mode patterns
derrickstolee Jan 11, 2021
ed11cfc
diff-lib: handle index diffs with sparse dirs
derrickstolee Jun 1, 2021
48fd25a
status: skip sparse-checkout percentage with sparse-index
derrickstolee Jan 15, 2021
3499105
status: use sparse-index throughout
derrickstolee Jan 8, 2021
60a6706
wt-status: expand added sparse directory entries
derrickstolee May 4, 2021
76bd8ec
fsmonitor: integrate with sparse index
derrickstolee Jan 15, 2021
a1a570a
Merge sparse-aware 'git status' into vfs-2.32.0
derrickstolee Jun 15, 2021
093a832
t1092: cleanups
derrickstolee Jun 17, 2021
722e7cd
fixup! unpack-trees: unpack sparse directory entries
derrickstolee Jun 17, 2021
9edbebf
fixup! unpack-trees: unpack sparse directory entries
derrickstolee Jun 17, 2021
0fda21d
fixup! t1092: expand repository data shape
derrickstolee Jun 17, 2021
610518c
fixup! unpack-trees: unpack sparse directory entries
derrickstolee Jun 17, 2021
320586f
fixup! dir.c: accept a directory as part of cone-mode patterns
derrickstolee Jun 17, 2021
ddaebb7
fixup! wt-status: expand added sparse directory entries
derrickstolee Jun 17, 2021
44bfb50
fixup! sparse-index: implement ensure_full_index()
derrickstolee Jun 17, 2021
0c20b94
fixup! fsmonitor: integrate with sparse index
derrickstolee Jun 17, 2021
f462956
fixup! fixup! t1092: expand repository data shape
derrickstolee Jun 18, 2021
87a3a29
fixup! wt-status: expand added sparse directory entries
derrickstolee Jun 21, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions dir.c
Original file line number Diff line number Diff line change
Expand Up @@ -1397,6 +1397,17 @@ enum pattern_match_result path_matches_pattern_list(
strbuf_addch(&parent_pathname, '/');
strbuf_add(&parent_pathname, pathname, pathlen);

/*
* Directory entries are matched if and only if a file
* contained immediately within them is matched. For the
* case of a directory entry, modify the path to create
* a fake filename within this directory, allowing us to
* use the file-base matching logic in an equivalent way.
*/
if (parent_pathname.len > 0 &&
parent_pathname.buf[parent_pathname.len - 1] == '/')
strbuf_add(&parent_pathname, "-", 1);
Copy link
Member

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 -?

Copy link
Author

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?

Copy link
Author

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:

  • The recommendation here is clever: path/to/directory/. is semantically identical to path/to/directory, so . is a natural option here.
  • This relies on the cone-mode path-checking logic to be ignorant of this meaning of the trailing /.. 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.

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.)


if (hashmap_contains_path(&pl->recursive_hashmap,
&parent_pathname)) {
result = MATCHED_RECURSIVE;
Expand Down