commit-graph parser

[avoidscorn]

I have a project that would benefit from being able to make reachability queries using only commit-graph files, so I'm interested in adding support for reading commit-graph files to this project.

The README mentions commit graphs would be part of git-repository, but commit graphs feel more like git-odb's pack indices to me. In particular, I think it could share the fan-out and oid-bisect code from git-odb/pack/index. The reachability code could still be in git-repository.

So:

1. Do you have a strong preference where commit graph I/O should go?
2. I assume adding read-only support is acceptable for now. Is this correct?

[Byron]

Thanks for your interest!

Indeed, the git-repository is just a catch-all, and I generally organize code by its dependencies to other crates. From the first looks it seems that it's a fairly well separated concept. Strictly optional, and really a file format to help speed up certain kinds of commit graph queries.

Reading the fanout and bisect code is quite trivial, and I clearly prefer putting everything into its own crate, also because there is no other relation to an object database. There will be quite some support code needed for (eventually) creating and maintaining the format, and a crate appears like an optimal container for that.

To answer the questions more succinctly:

1. Do you have a strong preference where commit graph I/O should go?

Their own crate, see the git-commitgraph crate I just created.

2. I assume adding read-only support is acceptable for now. Is this correct?

Absolutely. It has to start somewhere and reading is usually easier than writing.

How do you imagine contributing to this project?

[avoidscorn]

A separate crate sounds great!

How do you imagine contributing to this project?

I'm not sure what you're asking exactly, but my answer is yes!

[Byron]

I think I tried to ask about how that collaboration would look like.

Here are my suggestions on how I imagine the contribution process to look like, please chime in if there is something to discuss or alter.

• create a draft PR to allow early feedback
• use quick-error for errors exclusively
• organize modules similarly to how it is done in all the crates
• tests are a must have
• keep test fixtures small in the range of a few kilobytes, I try to avoid introducing git LFS.
• avoid extra crate dependencies by using callbacks to be passed in
• 'keep it lean' :D

As the commit-graph seems like an optimization, it will probably be coming very late to my task list, and I would be surprised if I feel the need for it in the coming months. This gives you some time to sketch it out.

Please let me know if there are any questions, I am happy to help.

[Byron]

With the PR merged, I believe this issue can be closed - thanks a lot for your contribution! Version 0.1 of the git-commitgraph crate was just published.