4 ms·

I just took a quick look at the code. This is non-persistent as it relies on the global `$ITEMS`, right? What benefit would this bring over simply storing direc

I just took a quick look at the code. This is non-persistent as it relies on the global `$ITEMS`, right? What benefit would this bring over simply storing directly into the variable?

rhgraysonii 11y ago
> This is non-persistent as it relies on the global `$ITEMS`, right? In a sense. $ITEMS is a hash ruby-object whose keys are what is set as the key by the input, but its values are the hashes that are stored in the git filesystem. There are about 10,000,000 improvements this could have and by no means would I consider it production quality software. Any ideas on a better means of persistance knowing this? Could back up the dict itself as a string in the git filesystem and have it be restorable on instantiation, possibly...
- TimWolla 11y ago
  You should take a look at the garbage collector (git gc) of git as well. I'm pretty sure that it'll clean up your KV-store, as the objects are not referenced anywhere. Choose a storage model that'll survive `git gc`. Maybe take a look at the tree objects git itself uses?
  - rhgraysonii 11y ago
    This would hopefully play well with the potential of use of a more robust git tooling like rubiquity had mentioned in another comment. I had thought about the gc aspect but didn't dive into it too much since its so immature still. Definitely will be considering all this as I plan 0.3. Thanks.