-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix timestamps from git #43
Conversation
also updates to current irmin (0.11.0) and has some stylistic fixes |
hmm, with irmin 0.10.1 this doesn't seem to work well... |
for 0.10.1, I have another branch there since 0.11.0 doesn't like xen (see mirage/ocaml-git#151) |
(which I actually have deployed now on https://hannes.nqsb.io -- it first each key to a (timestamp, data) list (if the key is present in a commit), then sorts this list based on timestamp, and extracts the first (as |
Thank you for taking time with this issue. :) |
I don't understand much... what imho should be done in a future version is to a) pull b) find all articles) c) go over each commit, look which articles are modified d) have the created and update timestamps (rather than go over each commit for each article, as done atm) |
(but I've decided to not touch the code anymore until I get git-1.8.0 (or above) working on Xen...) imho my last commit in the irmin-0.10.1 branch makes it much cleaner, although for irmin-0.11.0 I guess we can assume that the |
Yup, this is something I had in mind, shouldn't be too hard to do. |
not sure what makes sense for Canopy master, I'll for sure stay on my irmin-0.10.1 branch until further notice... feel free to merge whatever you like ;) (both branches improve the situation imho, whereas this one only works with 0.11.0)... |
fixes #33 and #41
instead of traversing the history twice, we now do it only once (per key), using topological.fold (thus going through the commits in order from first to last).
we read whether the key is in the temporary store, and what the last value of the key was:
if there was no last value, and there is now one, we're lucky -- this is the created commit
if there was a last value, and its the same as now, there wasn't a change to that specific key
if there was a last value, and the one now is different, we adjust the updated commit
if there was a last value, and none now, we basically ignore (since we do this only over all current keys, deletion does not happen)
in HEAD~1 I had some debug output in case there's some issue with the code...