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

worktree stack supports excludes #397

Merged
merged 121 commits into from
Apr 30, 2022
Merged

worktree stack supports excludes #397

merged 121 commits into from
Apr 30, 2022

Conversation

Byron
Copy link
Owner

@Byron Byron commented Apr 21, 2022

A way to obtain a set of attributes given a path, efficiently.

Each path we handle needs one lookup there during checkout, thus
it must be lazy and per thread.

git seems to implement it as stack which is efficient if similar paths are handled together,
and then drops information as it is no longer needed. This seems like the way to go
as we never have to optimize for random access.

Tasks

  • study existing dircache stack and see if it can be generalized
  • implement stack for git-ignore and use git-glob for matching and be sure dir-excludes work
  • gix repo exclude query

Byron added 30 commits April 21, 2022 11:25
It doesn't work as one would expect due to it wanting to match relative
paths only. Thus it's better to spare folks the surprise and instead
use `wildmatch()` directly. It works the same, but doesn't
have certain shortcuts which aren't needed for standard matches
anyway.
It caches as much as it can for each pattern list.

Many more tests are needed, but that will come in with
tests that compare git with our implementation.
Also allow to read from bytes directly, which happens if the file is
read from the index/odb.
Also it turns out that we can't really unify the pattern list creation
yet, unless we'd add parse errors to the trait which maybe is preferable
over duplicating some code.
…which haven't been covered by tests and which show that the current
implementation isn't sufficient.

It also makes clear that the match styles of git-attributes and
git-ignore are quite different.

It's unclear why, even though the way both algorithms work are
quite different. So have to take a step back and find a way
to figure it out.
The failing tests are due to shortcomings in git-glob pattern matching
right now.
…#301)

The stack-based matching is responsible for excluding entire directories
which is something the git-attributes based matching doesn't do.
Byron added 28 commits April 28, 2022 18:57
…301)

This makes it easier to work with errors in practice, we are either
interested in the value that failed to parse to try something else
or want a nice user message.

Having one decode error type facilitates that.
This way the original pattern can be reproduced on the fly without
actually storing it, saving one allocation.
…but it feels a little like a hack. Maybe this should tell us that
we need to reorganize code elsewhere?
Very similar to `string()`, but as path, whose query can never fail.
That way it's possible to call certain methods that take a separate
path buffer.
XDG home is still needs to be made accessible, along with a few other
improvements.
A lightweight, general purpose error to display permissions violations
that cause errors. This should make it useable across crates.
…ery` (#301)

Details are still to be fixed, and reading from stdin should be
implemented one day.

Issue right now is that the source path is normalized for some reason,
let's see where that happens.
If and only if it canonicalized the source path. That way, users will
still get a familiar path. This is due to `parent()` not operating
in the file system, which otherwise would be equivalent to `..`,
but that's not how we work.

Maybe we should overhaul the way this works to use `../` instead
and just 'absoluteize' the path later (std::path::absolute()) is
on the way for that.
It doesn't reproduce on a local VM though.
@Byron Byron merged commit 98da8ba into main Apr 30, 2022
@Byron Byron deleted the worktree-stack branch April 30, 2022 02:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant