inaimathi
commented
10 years ago The main thing that would discount libgit2 for me is that it looks like calling it would be more complicated than shelling out to git, and all it would get me is some performance (and admittedly side-step some implementation-specific road-bumps I'm hitting with regards to run-program).
I'm intending to put together the quick-and-dirty version first, get it working properly from a users' perspective, then port along pieces that need to be faster as I go. If that turns out to be necessary, I'll probably be using cl-git instead of rolling my own bindings.
I think this can make a very nice facility. I've had similar thoughts about doing this sort of thing to support a serialization, persistence type functionality but eventually in my case it seemed to be a bit more straightforward to use mmap and managing the bits directly.
One thing I'm wondering is if you considered leveraging libgit2 which is provides a native library you would then access visit CFFI (or CL-GIT which wraps the lower level interface with a higher-level lispy API). This would potentially eliminate a substantial amount of latency over using git directly by repeatedly invoking it as a shell command. So my question is if you'd looked at libgit2 and disqualified it for some reason -- and if so, if you might advise me what were the basic issues that led to that decision? Could potentially save me from falling into difficulties if I were to try using libgit2 sometime down the road.
Best Regards, Dan