procedure
( git_odb_add_alternateodbbackendpriority)→integer?
odb:odb?backend:odb_backend?priority:integer?
Alternate backends are always checked for objects after all the main backends have been exhausted.
The backends are checked in relative ordering, based on the value of the priority parameter.
Writing is disabled on alternate backends.
Read for more information.
procedure
( git_odb_add_backendodbbackendpriority)→integer?
odb:odb?backend:odb_backend?priority:integer?
The backends are checked in relative ordering, based on the value of the priority parameter.
Read for more information.
Note that the added path must point to an objects, not to a full repository, to use it as an alternate store.
Alternate backends are always checked for objects after all the main backends have been exhausted.
Writing is disabled on alternate backends.
procedure
compression_leveldo_fsyncdir_modefile_mode) → odb_backend?objects_dir:string?compression_level:integer?do_fsync:boolean?dir_mode:exact-positive-integer?file_mode:exact-positive-integer?
index_file:string?
This can be useful for inspecting the contents of a single packfile.
objects_dir:string?
procedure
( git_odb_existsdbid)→boolean?
db:odb?id:oid?
procedure
( git_odb_exists_prefixoutdbshort_idlen)→boolean?
out:oid?db:odb?short_id:oid?len:integer?
Note that since this function operates on multiple objects, the underlying database will not be asked to be reloaded if an object is not found (which is unlike other object database operations.)
The callback will be called for each object available in the database. Note that the objects are likely to be returned in the index order, which would make accessing the objects in that order inefficient. Return a non-zero value from the callback to stop looping.
procedure
( git_odb_freedb)→void?
db:odb?
odb:odb?pos:integer?
The resulting SHA-1 OID will be the identifier for the data buffer as if the data buffer it were to written to the ODB.
procedure
( git_odb_init_backendbackendint)→integer?
backend:odb_backend?int:unsigned
Before the ODB can be used for read/writing, a custom database backend must be manually added using git_odb_add_backend()
procedure
( git_odb_num_backendsodb)→integer?
odb:odb?
procedure
( git_odb_object_dataobject)→bytes?
object:odb_object?
This is the uncompressed, raw data as read from the ODB, without the leading header.
This pointer is owned by the object and shall not be free’d.
The returned copy must be manually freed with git_odb_object_free. Note that because of an implementation detail, the returned copy will be the same pointer as source: the object is internally refcounted, so the copy still needs to be freed twice.
procedure
( git_odb_object_freeobject)→void?
object:odb_object?
This method must always be called once a git_odb_object is no longer needed, otherwise memory will leak.
This is the OID from which the object was read from
procedure
( git_odb_object_sizeobject)→integer?
object:odb_object?
This is the real size of the data buffer, not the actual size of the object.
objects_dir:string?
- git_odb_backend_loose: read and write loose object files from disk, assuming ‘objects_dir‘ as the Objects folder
- git_odb_backend_pack: read objects from packfiles, assuming ‘objects_dir‘ as the Objects folder which contains a ’pack/’ folder with the corresponding data
Note that most backends do not support streaming reads because they store their objects as compressed/delta’ed blobs.
It’s recommended to use git_odb_read instead, which is assured to work on all backends.
The returned stream will be of type GIT_STREAM_RDONLY and will have the following methods:
- stream->read: read ‘n‘ bytes from the stream - stream->free: free the stream The stream must always be free’d or will leak memory.
The type and final length of the object must be specified when opening the stream.
The returned stream will be of type GIT_STREAM_WRONLY, and it won’t be effective until git_odb_stream_finalize_write is called and returns without an error
The stream must always be freed when done with git_odb_stream_free or will leak memory.
This method queries all available ODB backends trying to read the given OID.
The returned object is reference counted and internally cached, so it should be closed by the user once it’s no longer in use.
procedure
( git_odb_read_headerlen_outtype_outdbid)→integer?
len_out:(cpoinersize)type_out:(cpointergit_otype)db:odb?id:oid?
The header includes the length and the type of an object.
Note that most backends do not support reading only the header of an object, so the whole object will be read and then the header will be returned.
db:odb?short_id:oid?len:integer?
This method queries all available ODB backends trying to match the ’len’ first hexadecimal characters of the ’short_id’. The remaining (GIT_OID_HEXSZ-len)*4 bits of ’short_id’ must be 0s. ’len’ must be at least GIT_OID_MINPREFIXLEN, and the prefix must be long enough to identify a unique object in all the backends; the method will fail otherwise.
The returned object is reference counted and internally cached, so it should be closed by the user once it’s no longer in use.
procedure
( git_odb_refreshdb)→integer?
db:odb?
If the object databases have changed on disk while the library is running, this function will force a reload of the underlying indexes.
Use this function when you’re confident that an external application has tampered with the ODB.
NOTE that it is not necessary to call this function at all. The library will automatically attempt to refresh the ODB when a lookup fails, to see if the looked up object exists on disk but hasn’t been loaded yet.
procedure
( git_odb_stream_finalize_writeoutstream)→integer?
out:oid?stream:odb_stream?
The object will take its final name and will be available to the odb.
This method will fail if the total number of received bytes differs from the size declared with git_odb_open_wstream()
procedure
( git_odb_stream_freestream)→void?
stream:odb_stream?
procedure
( git_odb_stream_readstreambufferlen)→integer?
stream:odb_stream?buffer:bytes?len:integer?
Most backends don’t implement streaming reads
procedure
( git_odb_stream_writestreambufferlen)→integer?
stream:odb_stream?buffer:string?len:size_t
This method will fail if the total number of received bytes exceeds the size declared with git_odb_open_wstream()
procedure
( git_odb_writeoutodbdatalentype)→integer?
out:oid?odb:odb?data:bytes?len:integer?type:git_otype
This method writes a full object straight into the ODB. For most cases, it is preferred to write objects through a write stream, which is both faster and less memory intensive, specially for big objects.
This method is provided for compatibility with custom backends which are not able to support streaming writes
db:odb?progress_cb:git_transfer_progress_cbprogress_payload:bytes?
If the ODB layer understands pack files, then the given packfile will likely be streamed directly to disk (and a corresponding index created). If the ODB layer does not understand pack files, the objects will be stored in whatever format the ODB layer uses.