¿Cuál es la ventaja de comprometerse con la database de objects Git?

En la discusión entre los comentarios en este número de libgit2sharp, ¿ se ha resaltado que puedo crear confirmaciones contra la database de objects?

¿Qué está comprometiendo con la database de objects?

¿Por qué es ventajoso sobre hacer un git add normal y un commit de git?

Estoy intentando importar el historial de confirmaciones de otro sistema de control de fuente, SourceGear, a Git. Por el momento, mi lógica simplemente hace un bucle sobre los files en el otro sistema de control de fuente, obtiene una cierta versión y su información de confirmación y hace un repo.Index.Stage y luego repo.Commit . Supongo que es correcto, ¿debería usar la database de objects?

Al trabajar contra LibGit2Sharp, la forma estándar de confirmación es, de hecho, el siguiente flujo de trabajo:

 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 } 

Sin embargo, esto requiere un Repositorio no desnudo: un repository con un directory de trabajo y un índice .

La llamada a Stage() registra los files de su directory de trabajo en el índice . La llamada a Commit() crea una instantánea inmutable con timestamp del contenido del índice en la database de objects .

Desde la versión v0.9, LibGit2Sharp permite la creación directa de Commits en la database de objects sin necesidad de Stage() . De hecho, esto incluso funciona contra depósitos desnudos.

Además de Commits, al usar la nueva API ObjectDatabase , uno puede crear Blobs o Trees . Se pueden encontrar algunas muestras de posible uso en las testings de la unidad ObjectDatabaseFixture .

¿Qué está comprometiendo con la database de obect?

De hecho, un Commit siempre termina almacenado en la database de objects. La nueva API expone algunas operaciones de nivel inferior que pueden ser útiles en algunas operaciones avanzadas de scripting.

¿Por qué es ventajoso sobre hacer un git add normal y un commit de git?

Wow … Esta es una sub-pregunta amplia. Y no hay una list finita de respuestas 😉 Aquí hay algunas posibles respuestas:

  • Esto le permite crear Blobs y / o Trees directamente, independientemente de cualquier Commit
  • Usando el working directory -> index -> odb estándar working directory -> index -> odb trabajo working directory -> index -> odb , uno solo puede preparar un compromiso a la vez. Al usar esta API, puedes crear Blobs y Trees en un flujo no secuencial, y luego decidir en el último momento qué Tree estará asociado a un Commit.
  • Esta API también permite seleccionar explícitamente qué padres debe asumir el compromiso que se creará
  • Git es un sistema de files direccionable por contenido, una database de objects anexa e inmutable. Esta API facilita otro tipo de uso que el control de fuente estándar.

Por el momento, mi lógica simplemente hace un bucle sobre los files en el otro sistema de control de fuente, obtiene una cierta versión y su información de confirmación y hace un repo.Index.Stage y luego repo.Commit. Supongo que es correcto, ¿debería usar la database de objects?

Teniendo en count su caso de uso, parece que el flujo de trabajo estándar es suficiente.