On Tue, Jun 28, 2016 at 3:14 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Duy, > > On Tue, 28 Jun 2016, Duy Nguyen wrote: > >> On Tue, Jun 28, 2016 at 11:40 AM, Johannes Schindelin >> <johannes.schinde...@gmx.de> wrote: >> > >> > On Mon, 27 Jun 2016, Duy Nguyen wrote: >> > >> >> On Mon, Jun 27, 2016 at 7:38 AM, <larsxschnei...@gmail.com> wrote: >> >> > ## Proposed solution >> >> > Git LFS caches its objects under .git/lfs/objects. Most of the time >> >> > Git LFS objects are already available in the cache (e.g. if you >> >> > switch branches back and forth). I implemented these "cache hits" >> >> > natively in Git. Please note that this implementation is just a >> >> > quick and dirty proof of concept. If the Git community agrees that >> >> > this kind of approach would be acceptable then I will start to work >> >> > on a proper patch series with cross platform support and unit >> >> > tests. >> >> >> >> Would it be possible to move all this code to a separate daemon? >> >> Instead of spawning a new process to do the filtering, you send a >> >> command "convert this" over maybe unix socket and either receive the >> >> whole result over the socket, or receive a path of the result. >> > >> > Unix sockets are not really portable... >> >> It's the same situation as index-helper. I expect you guys will >> replace the transport with named pipe or similar. > > Yes, I will have to work on that. But I might need to ask for a change in > the design if I hit some obstacle there: named pipes are not the same at > all as Unix sockets. > > Read: it will be painful, and not a general solution. So every new Unix > socket that you introduce will introduce new problems for me.
I thought we could have a drop-in replacement (or maybe a higher abstraction that would be sufficient for git). Thanks for pointing it out. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
