On Tue, Mar 1, 2016 at 8:35 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2016-03-01 at 08:31 +0700, Duy Nguyen wrote: >> On Tue, Mar 1, 2016 at 7:53 AM, David Turner < >> dturner@xxxxxxxxxxxxxxxx> wrote: >> > +Weaknesses: >> > +----------- >> > + >> > +The reflog format is somewhat inefficient: a binary format could >> > store >> > +reflog date/time information in somewhat less space. >> >> This raises an interesting question. What if we want to change lmdb >> format in future (e.g. to address this weakness)? Do we need some >> sort >> of versioning in lmdb database? I suppose you can always add "lmdb2" >> backend that shares most of the code with current lmdb backend. Not >> sure if that's what you had in mind though. > > The weakness of versioning inside the LMDB database is that in order to > check the version, you need to already have LMDB. That's the argument > for "lmdb2". > > I had sort of hoped that this version would be "good enough" that we > could avoid modifying it. So maybe that means we ought to address the > reflog format. But I'm not sure that it's that big a deal. What do > you think? I'm not using lmdb yet (can't because if I convert my git.git to use it, all topics I'm working on must be rebased on lmdb :-( ) so I don't have any strong opinion about this. As long as we have an escape hatch (that won't lead to a too messy future) I think we're good. Note that storing in binary also has disadvantage. If we move from SHA-1 to SHA-XXX in future, we can easily detect incorrect reflog line in text form, it's a bit harder to do in binary form when you pack everything (including some variable stuff like email) in one value. But I think we don't have to care about that right now, there will be lots of problems migrating to SHA-XXX anyway. -- Duy -- 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