5 ms·

I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20

I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do. There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS. Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git. I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.

acdha 12y ago
> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do. Maybe your team isn't a bunch of road-warriors but networks still drop packets, servers get overloaded and many people work remotely using imperfect VPNs & ISPs. It's really easy to forget how much time that used to waste but switching to Git meant that we no longer had daily chatter when any of those flared up & people just got on with life. That said, I'd love to see some focus on tooling which improves the painful parts you mentioned. I'd love to share binary data in Git and it's possible but painful. Similarly, the main selling point for Git on internal projects is the massive performance and usability wins over most of the competitors but there's no reason why that must be the case other than inertia on the part of the other options.
- Xylakant 12y ago
  Sure, networks drop packets and sometimes break down. But the number of issues with a solid office network is fairly low. Glass fiber, gigbit to the server. Folks don't work via VPN. I'm not pretending that the "road warrior" and remote worker use case isn't well served by git - but the "office worker tied to a desk" use case still exists. And from what I see is that it's more dominant than we'd expect.
  - wtetzner 12y ago
    > Folks don't work via VPN. Plenty of people work via VPN. Not just people that have remote jobs, but people that just work from home one or two days per week.
    - TeMPOraL 12y ago
      VPNs are sort of primarily used to work via them.
    - kedean 12y ago
      Don't forget everyone working for a consulting company.
  - acdha 12y ago
    > But the number of issues with a solid office network is fairly low The point was simply that “low” is not the same as “does not apply” and that matters when it's something which prevents someone from doing their job. Even when I worked at 100% on-site projects, I used git-svn so I could make local commits and ignore locking mishaps. Don't get me wrong, however, I'm totally in agreement for having better tools for supporting the local, centralized workflow. The other reason I used git-svn was because merging was much more reliable and I could rebase changes to squash commits before sharing them with others. All three of those features should work well in any serious version control system regardless of whether it's centralized.
    - sgift 12y ago
      Your machine will stop working sometimes, far more often than your office network stops working(1) and then all your nice little, local commits which haven't been pushed so far are down the gutter. There's always a trade-off, you just have to know it and work accordingly. (1) If this doesn't apply to your office network get a better network. Now.
      - acdha 12y ago
        This statement reflects a misunderstanding of the problem: In either case, you will lose unpublished work in the event of a catastrophic local drive failure. Only in the case of a centralized system, you will also be unable to work unless the entire network path and remote server is available. This will almost never be a question of data loss but it means that you will be unable to perform version control operations until it's resolved.
amyjess 12y ago
> I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there. Yes, I think what a lot of people forget is that git was designed specifically with the Linux kernel in mind. Linus wrote it to the workflow of his project without much regard for what other projects do. That's fine; there's nothing wrong with that at all. It just means that it's not suitable for every project, and that's a good thing: different types of projects should use tools that are actually designed for them. It also explains why git has such a strong learning curve: it was written for kernel hackers. The only people who were expected to use it are the kind of people who are used to delving deep into the nitty gritty. It's why I'm kinda disappointed GitHub became the dominant public source code host, because Mercurial is IMO much better at actually being penetrable to new users. I think people who are mostly familiar with SVN would be far, far more at home with Mercurial than git.
- silverbax88 12y ago
  Mercurial beats Git hands down across the board for me. I've worked on so many projects where the initial development was tossed into Git and then the devs spend three days trying to get their codebases synced and each using a different tool which may or may not implement the core commands of Git. Mercurial? Works everywhere much more simply, even ties into .NET with VisualHG and gives a better version/branch management than TFS. And doesn't mismanage disk space like Git. Mercurial + BitBucket is the cleanest, fastest way I have right now for adding devs to new projects. I avoid Git because so few people (ESPECIALLY those who have only used Git) understand source control well enough not to make a mess of it.
  - erikb 12y ago
    > each using a different tool which may or may not implement the core commands of Git That's really one of the core problems of using git and why it's not for everyone. If you want a tool to do your job then git won't make you happy. Using the core tools and learning how it works _inside_ is the only way to make it work efficiently. If you want/need a bike (something easy like svn), use a bike. If you want/need to use an air plane (git) you need to learn how to fly and that costs a lot of time. Putting something on the plane to make it look like a bike (a tool that may or may not enable all of git but probably not) won't suffice in either case.
jimktrains2 12y ago
> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do. Why must I be part of a team? Why can't I just be hacking randomly and syncing my history with my personal server as I feel like it.
- Xylakant 12y ago
  > Why must I be part of a team? Why can't I just be hacking randomly and syncing my history with my personal server as I feel like it. Sure, go, do. Just don't pretend that there are no teams and no other people that have different use cases.
  - Semiapies 12y ago
    Likewise, acknowledge that many other people have use cases where git works very well for them. That might have more to do with its popularity than a mad love for DVCS.
    - Xylakant 12y ago
      Go three post up, read the last paragraph. I'll quote it for your convenience: > I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.
      - Semiapies 12y ago
        Yes, and that argument was silly. There are many use cases besides dispersed teams and road warriors where git's weaknesses never actually come up and its strengths are useful. However, your arguments, like TFA's, rely on an unconvincing and entirely unproven premise that git doesn't actually suit most coders' use of it.
gnaffle 12y ago
> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do. It's not only "for local commits", although being able to have local branches without polluting a public namespace is a huge win. It's also about _speed_ when you're doing VCS operations. Linus Torvalds actually made the case really well in his talk: https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 > There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS. That's a question that's completely orthogonal to whether or not you use a DVCS. How is a "traditional" VCS going to help you when you can check out the code locally and smuggle it out on a flash drive? In my company, we use git and there are access restrictions as to who can access and commit to our branches. > Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git. ..and that's not the use case for git. Linus has been very clear about _what_ git is optimized for, performance wise. That doesn't mean that DVCSes in general are useless for storing large assets, but that the most popular implementation is. Also, I'm not really sure what traditional VCS you're referring to, that makes it easy to version VM images and remain storage efficient?

acdha 12y ago

> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do. Maybe your team isn't a bunch of road-warriors but networks still drop packets, servers get overloaded and many people work remotely using imperfect VPNs & ISPs. It's really easy to forget how much time that used to waste but switching to Git meant that we no longer had daily chatter when any of those flared up & people just got on with life. That said, I'd love to see some focus on tooling which improves the painful parts you mentioned. I'd love to share binary data in Git and it's possible but painful. Similarly, the main selling point for Git on internal projects is the massive performance and usability wins over most of the competitors but there's no reason why that must be the case other than inertia on the part of the other options.

Xylakant 12y ago
Sure, networks drop packets and sometimes break down. But the number of issues with a solid office network is fairly low. Glass fiber, gigbit to the server. Folks don't work via VPN. I'm not pretending that the "road warrior" and remote worker use case isn't well served by git - but the "office worker tied to a desk" use case still exists. And from what I see is that it's more dominant than we'd expect.
- wtetzner 12y ago
  > Folks don't work via VPN. Plenty of people work via VPN. Not just people that have remote jobs, but people that just work from home one or two days per week.
  - TeMPOraL 12y ago
    VPNs are sort of primarily used to work via them.
  - kedean 12y ago
    Don't forget everyone working for a consulting company.
- acdha 12y ago
  > But the number of issues with a solid office network is fairly low The point was simply that “low” is not the same as “does not apply” and that matters when it's something which prevents someone from doing their job. Even when I worked at 100% on-site projects, I used git-svn so I could make local commits and ignore locking mishaps. Don't get me wrong, however, I'm totally in agreement for having better tools for supporting the local, centralized workflow. The other reason I used git-svn was because merging was much more reliable and I could rebase changes to squash commits before sharing them with others. All three of those features should work well in any serious version control system regardless of whether it's centralized.
  - sgift 12y ago
    Your machine will stop working sometimes, far more often than your office network stops working(1) and then all your nice little, local commits which haven't been pushed so far are down the gutter. There's always a trade-off, you just have to know it and work accordingly. (1) If this doesn't apply to your office network get a better network. Now.
    - acdha 12y ago
      This statement reflects a misunderstanding of the problem: In either case, you will lose unpublished work in the event of a catastrophic local drive failure. Only in the case of a centralized system, you will also be unable to work unless the entire network path and remote server is available. This will almost never be a question of data loss but it means that you will be unable to perform version control operations until it's resolved.

amyjess 12y ago

> I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there. Yes, I think what a lot of people forget is that git was designed specifically with the Linux kernel in mind. Linus wrote it to the workflow of his project without much regard for what other projects do. That's fine; there's nothing wrong with that at all. It just means that it's not suitable for every project, and that's a good thing: different types of projects should use tools that are actually designed for them. It also explains why git has such a strong learning curve: it was written for kernel hackers. The only people who were expected to use it are the kind of people who are used to delving deep into the nitty gritty. It's why I'm kinda disappointed GitHub became the dominant public source code host, because Mercurial is IMO much better at actually being penetrable to new users. I think people who are mostly familiar with SVN would be far, far more at home with Mercurial than git.

silverbax88 12y ago
Mercurial beats Git hands down across the board for me. I've worked on so many projects where the initial development was tossed into Git and then the devs spend three days trying to get their codebases synced and each using a different tool which may or may not implement the core commands of Git. Mercurial? Works everywhere much more simply, even ties into .NET with VisualHG and gives a better version/branch management than TFS. And doesn't mismanage disk space like Git. Mercurial + BitBucket is the cleanest, fastest way I have right now for adding devs to new projects. I avoid Git because so few people (ESPECIALLY those who have only used Git) understand source control well enough not to make a mess of it.
- erikb 12y ago
  > each using a different tool which may or may not implement the core commands of Git That's really one of the core problems of using git and why it's not for everyone. If you want a tool to do your job then git won't make you happy. Using the core tools and learning how it works _inside_ is the only way to make it work efficiently. If you want/need a bike (something easy like svn), use a bike. If you want/need to use an air plane (git) you need to learn how to fly and that costs a lot of time. Putting something on the plane to make it look like a bike (a tool that may or may not enable all of git but probably not) won't suffice in either case.

jimktrains2 12y ago

Xylakant 12y ago
> Why must I be part of a team? Why can't I just be hacking randomly and syncing my history with my personal server as I feel like it. Sure, go, do. Just don't pretend that there are no teams and no other people that have different use cases.
- Semiapies 12y ago
  Likewise, acknowledge that many other people have use cases where git works very well for them. That might have more to do with its popularity than a mad love for DVCS.
  - Xylakant 12y ago
    Go three post up, read the last paragraph. I'll quote it for your convenience: > I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.
    - Semiapies 12y ago
      Yes, and that argument was silly. There are many use cases besides dispersed teams and road warriors where git's weaknesses never actually come up and its strengths are useful. However, your arguments, like TFA's, rely on an unconvincing and entirely unproven premise that git doesn't actually suit most coders' use of it.

gnaffle 12y ago

> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do. It's not only "for local commits", although being able to have local branches without polluting a public namespace is a huge win. It's also about _speed_ when you're doing VCS operations. Linus Torvalds actually made the case really well in his talk: https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 > There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS. That's a question that's completely orthogonal to whether or not you use a DVCS. How is a "traditional" VCS going to help you when you can check out the code locally and smuggle it out on a flash drive? In my company, we use git and there are access restrictions as to who can access and commit to our branches. > Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git. ..and that's not the use case for git. Linus has been very clear about _what_ git is optimized for, performance wise. That doesn't mean that DVCSes in general are useless for storing large assets, but that the most popular implementation is. Also, I'm not really sure what traditional VCS you're referring to, that makes it easy to version VM images and remain storage efficient?