Quick Start
A quick start guide to help you get started with Git Graph.
Let's create a simple Git repository and manage graph files with Git Graph. First, create a fresh directory.
Now, initialize a new Git repository.
Install Git Graph
Normally, Git Graph is installed globally, but you can install it locally to this repository by using the --local flag.
This command sets the graph drivers in the local repository's Git configuration.
Track Graph Files
After setting up the Git configuration, you can indicate which files Git Graph should manage with the following command:
Here, *.jsonl represents the pattern for filenames you wish to track. For more details on this pattern syntax, refer to the Git Attributes documentation.
The quotation marks surrounding the pattern are essential to prevent the shell from expanding the glob pattern.
Commit the .gitattributes file
Now, commit the .gitattributes file to the repository.
Create a graph file
Now, let's create a new simple PG-JSONL graph file named graph.jsonl.
This graph file is the same as the one in the Property Graph Exchange Format Specification.
We can then add and commit the graph file to the repository.
Now, let's edit the graph file and add a new node.
Before committing the changes, let's view the diff of the graph file.
Note that the graph file is in the PG-JSONL format, but the diff is displayed in JSON.
Now, instead of adding nodes, let's re-write the graph file with the original content with some changes.
If we re-run the git diff command, we can see the diff of the graph file.
As you can see, Git Graph is using the git diff textconv option to display the graph files in JSON format, which is very useful because it keeps each element of the graph on a single line. However, this is not always sufficient for the semantic diffing feature.
In this example we can see that the "engaged" property is changed from false to true and the "country" property is changed from "United States" to "USA", but we don't know from the git diff output which nodes were changed. In some cases, you can't even tell if it's a node or an edge that was changed.
Git Graph diff driver is only useful for simple changes (e.g. adding a new node). For more complex changes, you should use the git graph difftool command.
Before committing the changes, let's create a new branch called merge-conflict.
Now, commit the changes.
Switch back to the main branch.
Edit the graph file again.
Add and commit the changes.
Merge the merge-conflict branch into the main branch. You will see a merge conflict.
The conflict is caused by the "country" property the node with id 101 has. Following the 3-way merge strategy, Git Graph sees a BASE version of "United States", a OURS version of "U.S.", and a THEIRS version of "USA" for the same property, and it doesn't know which one to keep.
You can see from the git merge output that a new file was created, graph.jsonl.conflicts.json, which contains the conflicts of the merge.
But, before resolving the conflicts, let's see how the difftool driver can show the deltas between the BASE, OURS, and THEIRS versions of the graph file.
Although we can use the git difftool command to view the deltas between the BASE, OURS, and THEIRS versions of the graph file, the *.conflicts.json file is more useful for resolving the conflicts. Let's see it's content.
Will output:
The *.conflicts.json file is a JSON object with a conflicts array. Each conflict object contains the following properties:
type: The type of the conflict (node or edge)key: The key of the graph element that is in conflict (node_101, edge_101_102_directed, etc.)description: A natural language description of the conflictdata: Useful context for resolving the conflict with theBASE,OURS, andTHEIRSversions of the graph element.
How is this guide?