Question

In the discussion amongst the comments in this libgit2sharp issue it was highlighted I can create commits against the object database?

What is committing to the object database?

Why is advantageous over doing a normal git add and git commit?

I’m trying to import commit history from another source control system, SourceGear, into Git. At the moment my logic simply loops over the files in the other source control system, gets a certain version and its commit info and does a repo.Index.Stage and then repo.Commit. I’m assuming that is correct, should I use the object database?

Answer 1

When working against LibGit2Sharp the standard way to commit is indeed the following workflow:

using (var repo = new Repository("path/to/a/repository"))
{
    // do stuff

    repo.Index.Stage("path/to/file1");
    repo.Index.Stage("path/to/file2");

    repo.Commit("This is my commit", ....);

    // more stuff
}

However, this requires a non-bare Repository: a repository with a working directory and an index.

The Stage() call registers files from your working directory into the index. The Commit() call creates an immutable timestamped snapshot of the content of the index into the object database.

Since version v0.9, LibGit2Sharp allows the direct creation of Commits into the object database without requiring to Stage() anything. In fact, this even works against bare repositories.

Besides Commits, using the new ObjectDatabase API, one can create Blobs or Trees. Some samples of possible use can be found in the ObjectDatabaseFixture unit tests.

What is committing to the obect database?

In fact a Commit always ends up being stored into the object database. The new API exposes some lower level operations which may come handy in some advanced scripting operations.

Why is advantageous over doing a normal git add and git commit?

Wow… This is a broad sub-question. And there is not a finite list of answers 😉 Off the top of my head here are some potential answers:

• This allows you to directly create Blobs and/or Trees independently of any Commit
• Using the standard working directory -> index -> odb workflow, one can only prepare one commit at a time. Using this API, you could create Blobs and Trees in a non-sequential flow, then decide at the latest moment which Tree will be associated to a Commit.
• This API also allows to explicitly select what parents the Commit to be created should bear
• Git is a content-addressable filesystem, an immutable, append-only object database. This API facilitates other kind of usage than the standard source control one.

At the moment my logic simply loops over the files in the other source control system, gets a certain version and its commit info and does a repo.Index.Stage and then repo.Commit. I’m assuming that is correct, should I use the object database?

Considering your use case, it looks like the standard workflow is enough.