# Refactoring for larger repositories

The 0.7.x series of gleisbau is used for a major refactoring.
The target goal is to have the library ready for usage in [gitui](https://github.com/gitui-org/gitui),
an interactive application with requirements for start-up time,
memory usage, and rendering time. It must be possible to delegate
long running activities to a separate thread, and at the same time
render subsets of the graph in short time.

This can be achieved by splitting the library along some majour feature
lines:
- Traversing the graph to assign branch traces to commits
- Render a subset of the branch graph

Some final UI elements will be moved from the library to applications
(like git-graph), as they are less reusable.
- Printing of commit content
- Printing of SVG

All of this must be done while preserving some of [git-graph](https://github.com/git-bahn/git-graph)'s most noticable features:
- Configurable branch priority, ordering, and colouring
- Stable branch layout - the subset size should not affect how branches are rendered.

# Step: Introduce Builder

I need to split GitGraph into two parts: Mapping of tracks and layout of graph.
The GitGraph structure is used by applications as if it was the final render,
therefore it belongs with the layout. However, GitGraph::new does a full
mapping of tracks as well as layout.

This should be split into two steps, none controlled by GitGraph

- Tracking branches
- Layout of branches

The start of ths separation is to introduce the builder pattern. This is closer
to how the final code will work.

# Step: Split GitGraph

I need to split GitGraph data to get a different coupling.
This will be done so legacy code can still use GitGraph with only some
API changes.

Some are purely related to decoration, like a list of tags, branches for
a commit, as well as information about which commit is the current head.
In git-graph and git-igitt this was achieved via access to internal
structures in GitGraph. A similar set of data will be provided via
migration fuctions on GitGraph.

The new process must be able to produce topology data without any geometry
or presentation data. The first refactoring is to
reverse the link between BranchInfo and BranchViz.

- BranchInfo will be built when traversing the graph, and must not know
  anything about visualization.
- BranchViz will be built repeatedly when rendering, from BranchInfo.

AS-IS

```mermaid
classDiagram
  GitGraph --> BranchInfo 
  BranchInfo --> BranchVis
```

TO-BE

```mermaid
classDiagram
  TrackMap --> BranchInfo
  TrackLayout --> BranchVis
  GitGraph --> TrackMap
  GitGraph --> TrackLayout
  GitGraph --> LabelMap
```


# Step: Threading

The background build of topology information in TrackMap should be able
to run until a UI thread requests access. This is because git can deliver
many thousands of commits per second when walking the graph, and the UI
may only render on request or perhaps 20 times per second.

To achive this, we need to add an API for incremental updates of the
topology data, and support geometry generation from partial topology
data.

There will be no thread handling included, as this can be implemented
in many different ways.


# Step: Backend API

The backend is currently git2. Introduce a new API at the backend level
so gix or other version systems can be used.


# Step: Persistence (optional)

For large repo the topology is expensive to fully compute. Save it to disk
in a binary format.