On Mon, Jan 04, 2016 at 12:26:01PM -0800, Junio C Hamano wrote: > An API enhancement to allow us to handle refs in multiple > repositories separately would be a very welcome move (it would get > rid of the hacky interface for_each_ref_in_submodule(), for one > thing), but even after that happens, I'd expect we would have most > callers asking to interact with "the_backend", the single default > instance. I am just a bystander here, but I think I agree. I do not know how we will handle migrations from one format to another, but if we can instantiate two separate ref backends at once, it seems like we should be able to just for_each_ref() in the "old" backend, and update_ref() in the new one. I did not dig in the code, but I think that is similar to why we have the multiple-index code. It is not about juggling a bunch of independent instances, but about moving data between them (though not specifically for migration in the case of the index). As much as it would be nice to clean this up before moving to multiple backends, though, I don't think we should make it a pre-requisite. This is a difficult topic as it is, and I'd rather see us make incremental improvement (backends, then hopefully more flexible mixing of backends) than get bogged down and get neither. -Peff -- 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