Live data from Hacker News

Announcing GVFS: Git Virtual File System

blogs.msdn.microsoft.com

181–190 of 287 posts

Re: Announcing GVFS: Git Virtual File System

#181
post #146

Earlier quoted context omitted.

I think it's more naive to believe that large companies always make the right decisions. We see Microsoft make mistake after mistake (look at windows 8, windows vista). The only time they fix their mistakes is when they're made public. So there is no reason to fix their mistake of a code base.

It would be naive to assume large companies always make the right decisions, which is why few people do that. However, when you see that a large company is doing something in a way that you thing is silly or strange, the logical thing to ask first is "what do they understand that I don't understand?". It won't always be the case, of course, but most of the time it will turn out you were missing something. Assuming of…

>the logical thing to ask first is "what do they understand that I don't understand?".

There's even a name for this: "Going from D to C - from disparagement to curiosity". I think I first heard it from @patio11.

Re: Announcing GVFS: Git Virtual File System

#182

Don't believe in modular development with smaller repos?

Yeah, I see things like this, and I always wonder why they don't make a submodule tree.

It wasn't an option a couple years ago, but submodules work fine now. With a little bit of scripting to wrap common uses, they're practically pain-free.

Re: Announcing GVFS: Git Virtual File System

#183
Could this also help a smaller repo but with long history, making the total repo size too large?

The whole repo is needed for every developer - i.e it's not possible to do a sparse checkout but many gigs of old versions of small binaries I would prefer to keep only at the server until I need it (which is never).

Re: Announcing GVFS: Git Virtual File System

#184
MS has been doing really neat stuff lately. I never worked on a project that takes hours to clone. The largest repository I regularly clone is the Linux repo. It still takes only a few minutes. Yet I can see the GVFS being beneficial for me as I spend most of the time just reading the code (so no need to compile) on my laptop.

Re: Announcing GVFS: Git Virtual File System

#185

My sysadmin: "we won't switch to git because it can't handle binary files and our code base is too big" Our whole codebase is 800MB.

Our codebase (latest tree) is similar, but switching to git it's the total history size that is the problem. Our history is well over 25GB which git doesn't handle very gracefully.

Re: Announcing GVFS: Git Virtual File System

#186

It's interesting how all the cool things seem to come from Microsoft these days. I still think we need something better than Git, though. It brought some very cool ideas and the inner workings are reasonably understandable, but the UI is atrociously complicated. And yes, dealing with large files is a very sore point. I'd love to see a second attempt at a distributed version control system. But I applaud MS's initiati…

> but the UI is atrociously complicated

Linus himself admitted that he isnt good at UI. Anyway, I think git just wasnt designed to be used directly, but via another UI. For example, I use it within Visual Studio Code, and that covers about 90 percent of usecases, and then Git Extensions can take care of almost everything else. Sometimes cli is needed, though.

Re: Announcing GVFS: Git Virtual File System

#187

It's interesting how all the cool things seem to come from Microsoft these days. I still think we need something better than Git, though. It brought some very cool ideas and the inner workings are reasonably understandable, but the UI is atrociously complicated. And yes, dealing with large files is a very sore point. I'd love to see a second attempt at a distributed version control system. But I applaud MS's initiati…

> I'd love to see a second attempt at a distributed version control system. Out of curiosity, why a whole new attempt? Personally, I'd prefer the approach of "making our current tools better."

What are your thoughts on Pijul? (https://pijul.org)

Re: Announcing GVFS: Git Virtual File System

#188
post #181
post #146

Earlier quoted context omitted.

It would be naive to assume large companies always make the right decisions, which is why few people do that. However, when you see that a large company is doing something in a way that you thing is silly or strange, the logical thing to ask first is "what do they understand that I don't understand?". It won't always be the case, of course, but most of the time it will turn out you were missing something. Assuming of…

>the logical thing to ask first is "what do they understand that I don't understand?". There's even a name for this: "Going from D to C - from disparagement to curiosity". I think I first heard it from @patio11.

It isn't the snappiest label, but it does capture the idea well.

Re: Announcing GVFS: Git Virtual File System

#189
Or how about we start some compartmentalizing your codebase so that you can like. You know, organize your code and restore sanity to the known universe.

I think when the powers that be said that whole thing about geniuses and clutter, they were specifically talking about their living spaces and not their work...

Re: Announcing GVFS: Git Virtual File System

#190
post #179

Earlier quoted context omitted.

Git on Windows has gotten very fast and stable in the last few years. Microsoft employees themselves, among others of course, have directly contributed to a much better Git experience on Windows.

The reddit thread has quite a few people with opposing opinions, fwiw. Mostly "stuff that's ~instant on unix takes many seconds on Windows" and the like. It's true that Microsoft has contributed a lot (to the benefit of all), but from what I'm seeing it sounds like it's still lagging quite a bit. I haven't touched Windows in quite a while, so I can't really make a claim either way.

I'm at least speaking from daily use in my anecdotes. Apples for apples, yes Windows is going to lag behind Linux. [1] That doesn't mean it isn't fast and stable from the perspective of day-to-day Windows usage, and definitely as I stated in the previous comment, it is much faster and more stable on Windows today compared to Windows a few years ago.

Several of the anecdotes on the reddit thread don't even seem to take account what version the offending slowness was happening in, and anecdotally every time I've helped a Windows user experiencing slowness enough to complain about it, they've been years behind on their git version and installing the latest removed the complaints.

[1] ...and is just about guaranteed to in the many places in git where a command is still built as a tower of bash scripts calling perl scripts calling more bash scripts... If you read the changelogs, a lot of the performance optimizations that are helping every platform are the places where entire commands are getting replaced with C versions of themselves.

Post reply on HN