Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitfs

presslabs.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Gitfs

#21

Post by vtemian »

andrewstuart wrote: post #19

Python 2 only - disappointing.

Yeah...we know, but there is a plan of rewriting / refactoring some parts and we hope to port as much as we can from Python 2 to 3 by the end of this summer.

Thanks for reminding us ^_^

Re: Gitfs

#22

Post by andrewstuart »

vtemian wrote: post #21
andrewstuart wrote: post #19

Python 2 only - disappointing.

Yeah...we know, but there is a plan of rewriting / refactoring some parts and we hope to port as much as we can from Python 2 to 3 by the end of this summer. Thanks for reminding us ^_^

The whole "Python 2 only" thing feels pretty 2012.

Re: Gitfs

#23

Post by claudius »

mizzao wrote: post #4

It's great that git is super fast, but it seems like it would be pretty horrible at handing the binary files that would be needed for actual filesystem applications.

It depends on your usecase, I guess. Of course it won’t work for an entire operating system, but it doesn’t have to work for an entire operating system: It’s enough if it works for your current coding project, your directory of private documents or even dotfiles in your home directory.

Re: Gitfs

#25

Post by linkydinkandyou »

This could be useful, especially with extended "gits" that allow for easy manipulation of large binaries, when working with creative departments who aren't used to source-code control workflows. (Even in 2015, most art departments are still a mess of external drives and drop boxes)

Re: Gitfs

#26

Post by djm_ »

andrewstuart wrote: post #22
vtemian wrote: post #21

Earlier quoted context omitted.

Yeah...we know, but there is a plan of rewriting / refactoring some parts and we hope to port as much as we can from Python 2 to 3 by the end of this summer. Thanks for reminding us ^_^

The whole "Python 2 only" thing feels pretty 2012.

I accidentally upvoted your comment which is annoying as I think your attitude stinks. This is a useful project, what language it was or wasn't written in should be irrelevant. You'd already pointed out that it disappointed you, a pointless comment but fair enough, then you went on to rub it in further - was there a need for that? No.

Re: Gitfs

#27

Post by leni536 »

vtemian wrote: post #16
leni536 wrote: post #15

OK, the main page lacks information. https://www.presslabs.com/gitfs/docs/usage/ https://www.presslabs.com/gitfs/docs/arguments/ So apparently you can mount remotes, not only local .git dirs. This is really handy and it should be listed on the main page, really. I raises an other question: can I mount remotes where I don't have write access read-only? For the directory structure the history directory makes sense for…

I agree, the main page is a little bit outdated. You can mount remotes with where you have only read access, gitfs will fail to push something on the remote, and will put the entire repository in read-only. Right now, you don't have a read-only option, but it would be nice to have :) Great idea about tags and commits directories. It would be nice to specify at mount point, if you also want tags and/or commits etc. Yo…

Thanks, an other question: what happens when the remote can't fast-forward merge? I assume it doesn't force push.

Re: Gitfs

#28

Post by hollerith »

mizzao wrote: post #4

It's great that git is super fast, but it seems like it would be pretty horrible at handing the binary files that would be needed for actual filesystem applications.

That's not the intended use, though. It is intended as an alternative interface to ordinary git repos, not as an alternative way to store ordinary file systems.
Post reply on HN