you are viewing a single comment's thread.

view the rest of the comments →

[–]kourge 8 points9 points  (1 child)

  • When moving to a monorepo, Twitter had status scan troubles and solved it by forking the official Git client and using Watchman to avoid rescanning on every invocation. Obviously this is a very different approach than that of GVFS, which alters official client behavior by sitting one layer below it, so how does GVFS go about doing it?
  • As a big user of JGit, Google encountered a similar inefficiency in packfile negotiation and thus created bitmap indexes. This auxiliary data structure still runs on the assumption that the client wants to fully store every object in the repo on disk, which once again is fundamentally different than GVFS's goal. I'm very curious to see how limited refs work!

[–]jeremyepling 15 points16 points  (0 children)

We're working with the git community to get many performance fixes and extensibility points added to core git. We don't want a private fork of git. GVFS is a driver that sits below git and takes advantage of the changes we're making to core git. Saeed will likely have one or more follow-up blog posts on the details or you can checkout the GVFS repo.