Live data from Hacker News

Show HN: Gitfs – mount Git repos as local folders

presslabs.com

31–40 of 63 posts

Re: Show HN: Gitfs – mount Git repos as local folders

#32
post #4
post #2

Is this an alternative to cloning a repo and pushing changes or is this supposed to be used as a full filesystem? I don't quite understand the blurb.

Hi. I'm one of the authors of GitFS! It is supposed to work as a fully-fledged filesystem. Do you have in mind a particular use case?

makes sense as a simple deployment tool too i guess? simply mount the stable branch in your 'www' directory and you can push to deploy (for a static files based site at least).

Re: Show HN: Gitfs – mount Git repos as local folders

#35
post #27

Earlier quoted context omitted.

> (whereas with plaintext it can just store the diffs) git stores full blobs, not deltas.

I guess it depends how deep you dive... It is true that on the surface, git gives you the user access to full blobs only and calculates the difference every time you access blobs. But when you go in packfiles the content is actually diff'ed because it compresses so well. In the context of the discussion, since we're interested in the on-disk format, it's more accurate to say that git will try to diff binary blobs, fa…

Not everything is in packfiles right away.

Re: Show HN: Gitfs – mount Git repos as local folders

#36
post #31

How does it handle merge conflicts? Seems like an interesting idea, my concern would be that the abstraction of a filesystem on top of git would break down really quickly once multiples users started editing things.

Merging is pluggable and the currently implemented strategy is to merge always accepting the local changes. Actually we are currently using it in an environment in which multiple edits on the same file can be made and as in the case of "regular" filesystem the last one closing the file wins. The advantage is that you will have all the revisions.

Re: Show HN: Gitfs – mount Git repos as local folders

#37

I think this kind of file system would do well to power platforms that AREN'T for programmers. While this may not seem useful for programmers (because they are so involved in git usage in the first place), I think others might benefit I've had the idea to make an interative design/architecture plugin for programs like photoshop/3dmax/etc rolling around in my head for a while now. Git is a perfect way to store/save th…

It's my understanding that Git is pretty bad for storing binary files that change a lot since it has to keep a copy of every version of that file (whereas with plaintext it can just store the diffs). Now, maybe that's what you would want, but that repo is going to get very big very fast. Pulls won't be so bad if your machine already has all the commits, but cloning would be a nightmare. And it'll be taking up a lot o…

I remember trying candidely git and svn (around 2008 so..) on a webdev project involving many images including some xMB PSD files. Surprisingly the git repo grew sublinearly, while svn was absuperlinear.

With git packing, the full repo with a bit of history (mostly adding some php and a few images) ended up smaller than the original windows native folder. Version control and compression; nice :)

Re: Show HN: Gitfs – mount Git repos as local folders

#38
post #8
post #4

Earlier quoted context omitted.

Hi. I'm one of the authors of GitFS! It is supposed to work as a fully-fledged filesystem. Do you have in mind a particular use case?

No, I think the question is, what do you as an author of the software have in mind as a particular use case? Some examples of why someone would use this would be great.

We have given some answers (together with vtemian) related to some of the use cases that we see possbile and to the need that it led to its creation in the first place. But since it's open-source, we are also expecting fresh scenarios in which people would like to use it. Also, contributions are more than welcome! :)

Re: Show HN: Gitfs – mount Git repos as local folders

#39

What's the performance like? That was always the downside of Clearccase - all the indirecting slugged the machine.

As with performance it really depends on your workload. For mostly reads the performance should be quite good since access is mostly passtrough. This is almost true with writes.

Reading on "history" has a small performance penalty since if you are reading files which are packed they need to be unpacked on the fly.

Listing the "history" is quite fast. We tested on the WordPress repository that has around 17k commits and it takes ~4s first time and less than 1s afterwards.

Post reply on HN