4 ms·

It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other s

It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. There are some powershell wrappers that make it better.

jhasse 9y ago
> It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. For me, that's Windows' fault.
- staofbur 9y ago
  Not really. You could write a git client for windows that didn't have these issues.
  - jhasse 9y ago
    Yes, I would call those changes workarounds for Windows' bugs (incase-sensitive filesystem, no ssh infrastructure, ...). One of the reasons Git is slower on Windows, is that spawning processes is a lot slower than on Linux. Wouldn't you call that a bug?
    - pjmlp 9y ago
      No, because Windows wasn't designed to make Git fast. It is a bug on Git side if it fails to be platform independent and requires POSIX semantics to function properly.
      - jhasse 9y ago
        I wouldn't call "spawning processes isn't slow" or a fast filesystem POSIX semantics.
        pjmlp 9y ago
        Windows has built on the premise of multi-threading and a filesystem with rich semantics, not as yet another UNIX clone.
        staofbur 9y ago
        It certainly doesn't have a very good filesystem though. NTFS is horrible on lots of small files due to MFT contention. Even arguing with fstool for a bit doesn't improve it. Check out 50k files on Linux/OSX: 2 mins.. check out 50k files on windows ... 14 mins. And that's both SSD backed.
        pjmlp 9y ago
        It is just that wasn't designed with that specific use case in mind. But it was designed with file streams, user ACLs, easy integration points across office networks, extensible to virtual devices, and data safety with actual proper locking semantics in mind.
        staofbur 9y ago
        It's just crap at storing files!
        pjmlp 9y ago
        It is your point of view, the enterprise among Fortune 500 companies using it as their IT backbone have another point of view.
        staofbur 9y ago
        I work for a Fortune 500 and we don't like it either.
        deleted 9y ago
        [deleted]
stephenr 9y ago
Right, so again, I haven't used it, so I'm going on what I've read, but my understanding is that Mercurial (which is Python based) is much more Windows friendly, and I actually use Mercurial more than Git. But still, regardless of whose "fault" it is, I couldn't imagine doing dev on a windows machine, some of which is because of the vastly different environment.
- staofbur 9y ago
  Mercurial is much nicer on windows. Git could have been the same but it targeted unix likes to start with and didn't evolve into something even remotely portable for a while. I use fossil for my own projects. I find that agreeable on all platforms.

jhasse 9y ago

> It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. For me, that's Windows' fault.

staofbur 9y ago
Not really. You could write a git client for windows that didn't have these issues.
- jhasse 9y ago
  Yes, I would call those changes workarounds for Windows' bugs (incase-sensitive filesystem, no ssh infrastructure, ...). One of the reasons Git is slower on Windows, is that spawning processes is a lot slower than on Linux. Wouldn't you call that a bug?
  - pjmlp 9y ago
    No, because Windows wasn't designed to make Git fast. It is a bug on Git side if it fails to be platform independent and requires POSIX semantics to function properly.
    - jhasse 9y ago
      I wouldn't call "spawning processes isn't slow" or a fast filesystem POSIX semantics.
      - pjmlp 9y ago
        Windows has built on the premise of multi-threading and a filesystem with rich semantics, not as yet another UNIX clone.
        staofbur 9y ago
        It certainly doesn't have a very good filesystem though. NTFS is horrible on lots of small files due to MFT contention. Even arguing with fstool for a bit doesn't improve it. Check out 50k files on Linux/OSX: 2 mins.. check out 50k files on windows ... 14 mins. And that's both SSD backed.
        pjmlp 9y ago
        It is just that wasn't designed with that specific use case in mind. But it was designed with file streams, user ACLs, easy integration points across office networks, extensible to virtual devices, and data safety with actual proper locking semantics in mind.
        staofbur 9y ago
        It's just crap at storing files!
        pjmlp 9y ago
        It is your point of view, the enterprise among Fortune 500 companies using it as their IT backbone have another point of view.
        staofbur 9y ago
        I work for a Fortune 500 and we don't like it either.
        deleted 9y ago
        [deleted]

stephenr 9y ago

Right, so again, I haven't used it, so I'm going on what I've read, but my understanding is that Mercurial (which is Python based) is much more Windows friendly, and I actually use Mercurial more than Git. But still, regardless of whose "fault" it is, I couldn't imagine doing dev on a windows machine, some of which is because of the vastly different environment.

staofbur 9y ago
Mercurial is much nicer on windows. Git could have been the same but it targeted unix likes to start with and didn't evolve into something even remotely portable for a while. I use fossil for my own projects. I find that agreeable on all platforms.