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. Ciao, Dscho -- 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
