Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> This suggests to me that our current structure is best modeled as two
> independent reference back ends, with a third implementation of the same
> reference API whose job it is to compose the first two. In pseudocode,
> ...
That is an interesting view.
How does reflog fit into the picture? Is it a completely
independent thing that is called from any implementation of
ReferenceBackend interface?
> From this point of view it is clear that packing refs is not an
> operation that belongs in the ReferenceBackend API, but rather in the
> StackedReferenceBackend interface.
When an implementation of ReferenceBackend has skewed performance
characteristics (e.g. PackedReferenceBackend really prefers to be
modified in bulk), how would that interact with the abstraction?
For example, when the application does:
begin_transaction()
for ref in many_refs():
delete_reference(ref)
commit_transaction()
StackedReferenceBackend() that consists of Loose on top of Packed
may want to implement the commit phase like so:
- tell Packed backend to repack without the deleted refs
- tell Loose backend to delete the deleted refs
But the above would not quite work, as somebody needs to remove logs
for refs that were only in the Packed backend, and "repack without
these refs" API supported by the Packed backend cannot be that
somebody---"repack packed-refs without A B C" cannot unconditionally
remove logs for A B C without checking if A B C exists as Loose.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html