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

traverse-with-commitgraph #887

Closed
wants to merge 18 commits into from
Closed

traverse-with-commitgraph #887

wants to merge 18 commits into from

Conversation

Byron
Copy link
Owner

@Byron Byron commented Jun 7, 2023

Refactor gix-traverse commit walks to provide more information about the commits it sees
and also support using the commitgraph for the same.

This can trickle up to gix which will yield certain information faster, naturally, without the need for
specialized walks for many cases, leveraging the features that are already present.

Tasks

  • docs to help with what's currently there
  • rigorous cleanup and support for additional Commit information
  • gix-traverse support for commitgraphs
  • make the commit-graph easily usable from the gix iteration platform
  • gix uses new gix-traverse API for commit walks and wraps these.

Related to #853

Follow-up

Special-case for author-computation with commit-graph in ein t h. Only if one exists one (and we don't compute line/file changes), we can offload all work to a couple of threads.

Byron added 18 commits June 9, 2023 13:43
In short, one should use the `Graph` to obtain the tools necessary for potentially
accelerated, custom commit walks.
This is to more easily support custm graph walks later.
That way it's possible to either open the existing worktree index, or create one
in-memory by turning our HEAD tree into an index on the fly.
…ence().

Many users of attributes will just need to know that.
…rmation.

As part of the iteration, it will decode part of the commit and read parents and possibly
the commit time if time-based sorting is desired. These values will now be made available
instead of just the `id` of the commit.

This saves the caller time to parse the commit again in case it needs similar information.
…king.

That way, they can be more selectively used without pulling in all of `gix-revision`
…()` that also pops the key.

This aligns the method name with `peek()`, which also pops the key.
…onky & rename `Sorting::Topological` to `Sorting::BreadthFirst`.

This is now fixed by using a proven data structure, the `BinaryHeap` as priority
queue.

The rename is to differentiate `git log --topo-order` from what we are doing, which is actually quite
different.
…commitgraph.

That way, traversal speed is greatly improved for traversals that only need
access to parents and commit time, while still being more efficient if it
saves the caller to retrieve a commit again to parse it for parents.
…trolled via `revision::walk::Platform::use_commit_graph(toggle)`.

The commitgraph is a data structure to greatly accelerate commit walks. It is now supported and
used by default, but can be deactivated if desired.

Further, add `Repository::commit_cache()` for direct access to just the commit-graph datastructure,
without the extras provided by `gix_revision::Graph`.
THat's a better fix given its locaion in `gix-revision`, while differentiating
it further from the lower-level `commit-graph`.

Also rename `Repository::commit_cache()` to `::commit_graph()` now that the name is free.
…d`s.

This enables re-use of information that was already obtained, like the parents of
a commit and possibly its commit-time.
@Byron
Copy link
Owner Author

Byron commented Jun 9, 2023

merged (with slightly different commits)

@Byron Byron closed this Jun 9, 2023
@Byron Byron mentioned this pull request Jun 9, 2023
27 tasks
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.

1 participant