10 ms·

> Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging. N

> Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging. No, I fell in love with it because it was distributed and I could work without an Internet connection, which aren't prevalent everywhere, and even in my house, in a large city, can be iffy. By work I mean things like blame, bisect, log, &c not just committing. > Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. Well lucky him for only being able to code when he has a nice connection, not all of us do. Also, I like the distributed aspect as well. I like not having to give people commit access to my repo for them to have a proper dev env and then they can send me a patch or a PR and we can incorporate their changes. How would they be able to make any commits or anything otherwise without access to my repository?

grabcocque 12y ago
I fell in love with git because it's FAST. And it's fast because it's distributed.
- bryanlarsen 12y ago
  Have you ever used Perforce?
  - jimktrains2 12y ago
    You mean that proprietary code? No, I avoid non F/OSS at all costs.
    - politician 12y ago
      Wherein it is pointed out that Hacker News is proprietary software.
      - jcl 12y ago
        Really? https://github.com/wting/hackernews https://github.com/wting/hackernews
        squeaky-clean 12y ago
        Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".
        vonmoltke 12y ago
        https://github.com/wting/hackernews/blob/master/copyright https://github.com/wting/hackernews/blob/master/copyright
      - jimktrains2 12y ago
        Hacker News is a website (so even with their code being open-sourced, I cannot verify what exactly they're running anyway), not software I'm running (JS aside). The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that. I can choose not to run proprietary software without having to not use the web.
        CHY872 12y ago
        You sure about that? Your system will be full of proprietary firmwares, drivers, etc.
        jimktrains2 12y ago
        I avoid it as much as I possibly can. I don't know what more to tell you. I never said I'm proprietary code-free, but just that I avoid it at all costs. Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.
  - wtetzner 12y ago
    I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.
    - Xylakant 12y ago
      > With git, you don't have to worry about it. Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
      - icefox 12y ago
        But at least you can run git log and not have to wait minutes.
        Xylakant 12y ago
        True. You are spared some of the pain, but not all of it.
        konstruktor 12y ago
        Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...
      - deathanatos 12y ago
        > Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly. But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.) With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
  - gumby 12y ago
    Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
    - konstruktor 12y ago
      I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about. [1] http://research.google.com/pubs/pub39983.html http://research.google.com/pubs/pub39983.html
      - gumby 12y ago
        > I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries. However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.
    - craigching 12y ago
      > Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits. Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase). Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.
  - sergiotapia 12y ago
    I quit my job because we were stuck using Perforce - how's that? :P
    - craigching 12y ago
      Try the git-p4 contrib. It has its issues, but it's not bad if you're forced to use p4.
      - Crito 12y ago
        I'll second this. git-p4 kept me sane through several years of working in a very large perforce shop.
  - konstruktor 12y ago
    Perforce is not fast, it cheats: You tell the server in advance what you are doing, so that the submit is fast. This comes at a tremendous price: Your editor/IDE has to have a perforce plugin to do what should be the VCS' job (tell perforce what is happening in your workspace), and the connection to the server has to be reliable and low latency, lest you want to spend seconds every time you make an edit in a file that has not been checked out already. In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.
  - Crito 12y ago
    Perforce sucks. From a UX perspective, it really is rotten. Furthermore, contrary to popular belief, it scales poorly. Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo. I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.
  - kyrra 12y ago
    For those wondering, Perforce just announced their own DVCS implementation[0][1]. [0] http://www.perforce.com/blog/150303/introducing-helix http://www.perforce.com/blog/150303/introducing-helix [1] http://www.perforce.com/helix http://www.perforce.com/helix
  - eitland 12y ago
    I have used it for some full moons. I didn't like it. This was before I learned about DVCS, so my only real reference was SVN, but for what I did (medium-size business apps, a few years of history) I can't say it felt faster than SVN. OTOH Perforce had some serious downsides like * immature eclipse plugin (would crash eclipse more than once a week, forcing a full reset every.single.time) * no Netbeans plugin (back then) * the whole idea of having to decide in advance, -while in the office or otherwise connected, which files you needed to modify and therefore "check out" - * which brings me to the next problem: by default only one person can work at a file at the same time. YMMW, I see some people liking Perforce, OTOH I see people using Macs for coding as well. (That last part is tongue-in-cheek, yes, I really wish I liked Macs and I recommend everyone to consider them.)
cssmoo 12y ago
* until you work on a project which has a 9Gb repo and history...
- makmanalp 12y ago
  You can do a shallow clone in any reasonable versioning system: http://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow-clone-more-useful-than-it-makes-out http://stackoverflow.com/questions/6941889/is-git-clone-dept...
  - samastur 12y ago
    But then git blame or bisect don't really work anymore.
    - Tobani 12y ago
      It may work well enough.
    - IanCal 12y ago
      I'm not too sure what could be realistically done to implement offline bisect without getting the all the history you care about.
      - ufo 12y ago
        One approach would be to query the server for these operations. And unlike what happens in Git, where blame is an O(N) operation, a centralized server is free to spend some extra storage to add some caches or indexes to make these searches faster.
        IanCal 12y ago
        Querying the server rarely works when you're offline.
  - CHY872 12y ago
moogleii 12y ago
>Well lucky him for only being able to code when he has a nice connection, not all of us do. So basically, you're de facto the field tech example he gave, out in the virtual wilderness of iffy internet.
- jimktrains2 12y ago
  No, I'm not a field tech. I'm a hacker. I work where I am and when I'm in the mood. In a pavilon at the park and idea strikes? Hack! At home and my internet goes out? No Problem!
  - eos_styx 12y ago
    At the park when an idea strikes? Write it down on a piece of paper. No need to have your face buried in your computer every second you're at a park. Edit: All you have to do it jot down the idea if your worried you'll forget about it. You don't have to hand write out all the code that would be silly. I find having a small notebook with me is pretty handy.
    - vidarh 12y ago
      It's no better to have your face buried in sheets of paper. And who carries paper and pens around anyway?
      - worklogin 12y ago
        For the record, I carry a journal and pen in my pocket all the time. Writing down phone numbers and notes, taking a log of my life, keeping cards from businesses. Looking back through them is much more enjoyable than looking back through a Wordpress. http://shop.moleskine.com/FileLibrary/4be794eb3e094e59ac8a8fe44d744d98/cahier-journal-set-of-3-pocket-ruled-soft-cover-kraft-brown-fullsize-1.jpg http://shop.moleskine.com/FileLibrary/4be794eb3e094e59ac8a8f...
        vidarh 12y ago
drostie 12y ago
Well, I mean, the author goes on to make a bunch of salient points like the difficulty of diffs of nested directories (solved in [1] but not widely implemented) and saving all of the binary blobs in every checkout (solved by [2] which has not "won out"). I think the big thing with DVCSes is that you can pretend you have a client-server model with a handful of directories on your local machine. At one point at my present job I replayed a bunch of SVN history through Hg so that I could by-hand divide the work that had been done into a few named branches; this helped me to figure out where things had "gone wrong" in the project. It was really effective to just have a day of SVN update, hg diff, copy files to ../branch_name, commit to hg, rinse, repeat. What I really needed was indeed the "killer feature" that he's saying -- sane branching and merging -- but the fact that it was all easily contained in my filesystem was a nice plus. [1] http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf [2] http://darcs.net/Internals/CacheSystem#lazy-repositories-and-the-cache-system http://darcs.net/Internals/CacheSystem#lazy-repositories-and...
Xylakant 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. 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.
tootie 12y ago
Anyone can work without internet. You just don't commit. If you really need to commit without internet, you're probably an edge case. It's a bonus, but not something I'd choose a VCS system for. My central repo is where the build server is looking, so if I'm not connected, I'm not deploying no matter which VCS I have. The repo is most definitely centralized.
- StillBored 12y ago
  I suspect some of the down votes are because what you mean by commit and what a git user means by commit is different. I suspect that most people using git are "committing" in a way that would better be handled with a versioned file system. AKA, translated for the git people, "you can work without the internet, you just don't issue pull requests (or pull for that matter)". Where I work now we still use CVS, and frankly it works fine (even with large binaries checked in). I ran git-cvs for a while, and had a dozen different branches for all the separate features I was working on. Then I found I was spending a metric crapload of time messing with the version control rather than writing code. CVS may be basic, but in a way that is a plus. It strongly encourages you not to have 20 different features being worked on at the same time, then merging this piece here to that piece there. No, its simple: Work on one thing in your working directory, commit it to the head, pull everyone's changes, go work on the next thing. Repeat. Eventually I kicked my git-cvs to the curb for plain old CVS. Gives me more focus. Now I can waste the time I spent on stack overflow (learning how to fix my git screwups) posting here...
  - tootie 12y ago
    Yeah, I was using "commit" in the SVN sense. Which is another good complaint against git that it rewrote the established lexicon to mean different things. Sure a git commit may be technically equivalent to an SVN commit, but when I "commit" I mean that I'm blessing a change as ready to share via a shared repo.
icefox 12y ago
> I have wanted to have the full history while offline a grand total of maybe about six times. I have probably run git init in a directory at least once a month to have full tracking capability without the expense of setting up a "server". It says something that the author assumes that a DVCS can only exists if it has a central server and that your local copy is nothing but the "offline" copy. I have also run projects where the github repo was just a copy and the version on my box was the official repo. I also run expensive (cpu/time) scripts that walk over the projects history, something the server admin would never let me do. And then we get into the realm of very expensive hooks that run on my desktop and not on the "server". And lastly even in an always connected world if your server is in Australia you can't change the speed of light, hitting it from Germany will always be a long "slow" trip. Having the full repository at your disposal without being tied to some other authoritative repository provides a lot of flexibility and enables capabilities that are just not possible otherwise. Some features could easily be included in non-dvcs systems (such as local hooks), but I do not know if we would have seen their success without dvcs systems providing the means for exploration.
- craigching 12y ago
  Agree with you 100%, any project, no matter how small, gets "git init"ed with me simply to start tracking it in case I later regret that change I just made. And I love that if I need it on another machine it's just "git clone ssh://..." instead of having to setup a server.

grabcocque 12y ago

I fell in love with git because it's FAST. And it's fast because it's distributed.

bryanlarsen 12y ago
Have you ever used Perforce?
- jimktrains2 12y ago
  You mean that proprietary code? No, I avoid non F/OSS at all costs.
  - politician 12y ago
    Wherein it is pointed out that Hacker News is proprietary software.
    - jcl 12y ago
      Really? https://github.com/wting/hackernews https://github.com/wting/hackernews
      - squeaky-clean 12y ago
        Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".
        vonmoltke 12y ago
        https://github.com/wting/hackernews/blob/master/copyright https://github.com/wting/hackernews/blob/master/copyright
    - jimktrains2 12y ago
      Hacker News is a website (so even with their code being open-sourced, I cannot verify what exactly they're running anyway), not software I'm running (JS aside). The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that. I can choose not to run proprietary software without having to not use the web.
      - CHY872 12y ago
        You sure about that? Your system will be full of proprietary firmwares, drivers, etc.
        jimktrains2 12y ago
        I avoid it as much as I possibly can. I don't know what more to tell you. I never said I'm proprietary code-free, but just that I avoid it at all costs. Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.
- wtetzner 12y ago
  I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.
  - Xylakant 12y ago
    > With git, you don't have to worry about it. Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
    - icefox 12y ago
      But at least you can run git log and not have to wait minutes.
      - Xylakant 12y ago
        True. You are spared some of the pain, but not all of it.
      - konstruktor 12y ago
        Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...
    - deathanatos 12y ago
      > Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly. But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.) With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
- gumby 12y ago
  Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
  - konstruktor 12y ago
    I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about. [1] http://research.google.com/pubs/pub39983.html http://research.google.com/pubs/pub39983.html
    - gumby 12y ago
      > I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't. Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries. However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.
  - craigching 12y ago
    > Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce. Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits. Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase). Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.
- sergiotapia 12y ago
  I quit my job because we were stuck using Perforce - how's that? :P
  - craigching 12y ago
    Try the git-p4 contrib. It has its issues, but it's not bad if you're forced to use p4.
    - Crito 12y ago
      I'll second this. git-p4 kept me sane through several years of working in a very large perforce shop.
- konstruktor 12y ago
  Perforce is not fast, it cheats: You tell the server in advance what you are doing, so that the submit is fast. This comes at a tremendous price: Your editor/IDE has to have a perforce plugin to do what should be the VCS' job (tell perforce what is happening in your workspace), and the connection to the server has to be reliable and low latency, lest you want to spend seconds every time you make an edit in a file that has not been checked out already. In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.
- Crito 12y ago
  Perforce sucks. From a UX perspective, it really is rotten. Furthermore, contrary to popular belief, it scales poorly. Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo. I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.
- kyrra 12y ago
  For those wondering, Perforce just announced their own DVCS implementation[0][1]. [0] http://www.perforce.com/blog/150303/introducing-helix http://www.perforce.com/blog/150303/introducing-helix [1] http://www.perforce.com/helix http://www.perforce.com/helix
- eitland 12y ago
  I have used it for some full moons. I didn't like it. This was before I learned about DVCS, so my only real reference was SVN, but for what I did (medium-size business apps, a few years of history) I can't say it felt faster than SVN. OTOH Perforce had some serious downsides like * immature eclipse plugin (would crash eclipse more than once a week, forcing a full reset every.single.time) * no Netbeans plugin (back then) * the whole idea of having to decide in advance, -while in the office or otherwise connected, which files you needed to modify and therefore "check out" - * which brings me to the next problem: by default only one person can work at a file at the same time. YMMW, I see some people liking Perforce, OTOH I see people using Macs for coding as well. (That last part is tongue-in-cheek, yes, I really wish I liked Macs and I recommend everyone to consider them.)

cssmoo 12y ago

* until you work on a project which has a 9Gb repo and history...

makmanalp 12y ago
You can do a shallow clone in any reasonable versioning system: http://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow-clone-more-useful-than-it-makes-out http://stackoverflow.com/questions/6941889/is-git-clone-dept...
- samastur 12y ago
  But then git blame or bisect don't really work anymore.
  - Tobani 12y ago
    It may work well enough.
  - IanCal 12y ago
    I'm not too sure what could be realistically done to implement offline bisect without getting the all the history you care about.
    - ufo 12y ago
      One approach would be to query the server for these operations. And unlike what happens in Git, where blame is an O(N) operation, a centralized server is free to spend some extra storage to add some caches or indexes to make these searches faster.
      - IanCal 12y ago
        Querying the server rarely works when you're offline.
- CHY872 12y ago

moogleii 12y ago

>Well lucky him for only being able to code when he has a nice connection, not all of us do. So basically, you're de facto the field tech example he gave, out in the virtual wilderness of iffy internet.

jimktrains2 12y ago
No, I'm not a field tech. I'm a hacker. I work where I am and when I'm in the mood. In a pavilon at the park and idea strikes? Hack! At home and my internet goes out? No Problem!
- eos_styx 12y ago
  At the park when an idea strikes? Write it down on a piece of paper. No need to have your face buried in your computer every second you're at a park. Edit: All you have to do it jot down the idea if your worried you'll forget about it. You don't have to hand write out all the code that would be silly. I find having a small notebook with me is pretty handy.
  - vidarh 12y ago
    It's no better to have your face buried in sheets of paper. And who carries paper and pens around anyway?
    - worklogin 12y ago
      For the record, I carry a journal and pen in my pocket all the time. Writing down phone numbers and notes, taking a log of my life, keeping cards from businesses. Looking back through them is much more enjoyable than looking back through a Wordpress. http://shop.moleskine.com/FileLibrary/4be794eb3e094e59ac8a8fe44d744d98/cahier-journal-set-of-3-pocket-ruled-soft-cover-kraft-brown-fullsize-1.jpg http://shop.moleskine.com/FileLibrary/4be794eb3e094e59ac8a8f...
      - vidarh 12y ago

drostie 12y ago

Well, I mean, the author goes on to make a bunch of salient points like the difficulty of diffs of nested directories (solved in [1] but not widely implemented) and saving all of the binary blobs in every checkout (solved by [2] which has not "won out"). I think the big thing with DVCSes is that you can pretend you have a client-server model with a handful of directories on your local machine. At one point at my present job I replayed a bunch of SVN history through Hg so that I could by-hand divide the work that had been done into a few named branches; this helped me to figure out where things had "gone wrong" in the project. It was really effective to just have a day of SVN update, hg diff, copy files to ../branch_name, commit to hg, rinse, repeat. What I really needed was indeed the "killer feature" that he's saying -- sane branching and merging -- but the fact that it was all easily contained in my filesystem was a nice plus. [1] http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf [2] http://darcs.net/Internals/CacheSystem#lazy-repositories-and-the-cache-system http://darcs.net/Internals/CacheSystem#lazy-repositories-and...

Xylakant 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. 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.

tootie 12y ago

Anyone can work without internet. You just don't commit. If you really need to commit without internet, you're probably an edge case. It's a bonus, but not something I'd choose a VCS system for. My central repo is where the build server is looking, so if I'm not connected, I'm not deploying no matter which VCS I have. The repo is most definitely centralized.

StillBored 12y ago
I suspect some of the down votes are because what you mean by commit and what a git user means by commit is different. I suspect that most people using git are "committing" in a way that would better be handled with a versioned file system. AKA, translated for the git people, "you can work without the internet, you just don't issue pull requests (or pull for that matter)". Where I work now we still use CVS, and frankly it works fine (even with large binaries checked in). I ran git-cvs for a while, and had a dozen different branches for all the separate features I was working on. Then I found I was spending a metric crapload of time messing with the version control rather than writing code. CVS may be basic, but in a way that is a plus. It strongly encourages you not to have 20 different features being worked on at the same time, then merging this piece here to that piece there. No, its simple: Work on one thing in your working directory, commit it to the head, pull everyone's changes, go work on the next thing. Repeat. Eventually I kicked my git-cvs to the curb for plain old CVS. Gives me more focus. Now I can waste the time I spent on stack overflow (learning how to fix my git screwups) posting here...
- tootie 12y ago
  Yeah, I was using "commit" in the SVN sense. Which is another good complaint against git that it rewrote the established lexicon to mean different things. Sure a git commit may be technically equivalent to an SVN commit, but when I "commit" I mean that I'm blessing a change as ready to share via a shared repo.

icefox 12y ago

> I have wanted to have the full history while offline a grand total of maybe about six times. I have probably run git init in a directory at least once a month to have full tracking capability without the expense of setting up a "server". It says something that the author assumes that a DVCS can only exists if it has a central server and that your local copy is nothing but the "offline" copy. I have also run projects where the github repo was just a copy and the version on my box was the official repo. I also run expensive (cpu/time) scripts that walk over the projects history, something the server admin would never let me do. And then we get into the realm of very expensive hooks that run on my desktop and not on the "server". And lastly even in an always connected world if your server is in Australia you can't change the speed of light, hitting it from Germany will always be a long "slow" trip. Having the full repository at your disposal without being tied to some other authoritative repository provides a lot of flexibility and enables capabilities that are just not possible otherwise. Some features could easily be included in non-dvcs systems (such as local hooks), but I do not know if we would have seen their success without dvcs systems providing the means for exploration.

craigching 12y ago
Agree with you 100%, any project, no matter how small, gets "git init"ed with me simply to start tracking it in case I later regret that change I just made. And I love that if I need it on another machine it's just "git clone ssh://..." instead of having to setup a server.