6 ms·

As a "younger" programmer it always shocks me how things like git were only created in 2005. It feels so ubiquitous and the way it functions has the "feeling" o

by teqsun 2y ago

As a "younger" programmer it always shocks me how things like git were only created in 2005. It feels so ubiquitous and the way it functions has the "feeling" of something created in the 80s or 90s to me.

vehemenz 2y ago
As an "older" programmer, I feel the opposite. Git became mainstream very recently, though admittedly it's been a good ten years or more. I sometimes think younger programmers' attitudes toward git are borderline cultish—git or GitHub is not required to do programming—it's just another tool. I half expected something would have replaced it by now.
- schacon 2y ago
  Git's been around for almost 20 years now. I would say fairly dominant for 15 or so.
- keybored 2y ago
  Git is overrated for a DVCS. But it’s not overrated considering the old-school competition like SVN. The assumptions of SVN makes it feel like a dinosaur now.
  - deleted 2y ago
    [deleted]
- gmueckl 2y ago
  I have to agree on the cult aspect. This is unfortunate because better tools exist already today, but lots of people refuse to even entertain that possibility.
  - teqsun 2y ago
    I feel about git how I presume vim users feel. Maybe there are better ways, but I've become so accustomed to how it works that I doubt I could easily switch to anything else.
    - gmueckl 2y ago
      All the more reason to look beyond your comfort zone now and then!
- golergka 2y ago
  Already in 2010-2012 majority of projects I encountered were using git. Last time I saw an SVN-based project was in 2015, before I migrated it to git.
eterm 2y ago
Subversion (svn) was absolutely fine before git. Before that, there was CVS but that really was painful. Svn gets a lot of hate for things it doesn't deserve, even this article talks about "checking out" and the difficulty of branching, but that doesn't track with subversion. Branching in subversion was just as easy as in git, it had shallow branches. You could branch largely without overhead, although unlike git it was a server-side operation. ( Imagine it like git branch with auto-push to remote). Most software also automatically checked out files as you modified them, and it was a local oepration, there wasn't any locking or contention on that. It was the older CVS/sourcesafe style version system that those. I still maintain that most workplaces with less than, say, 10 devs, would be better off with subversion rather than git, if not for the fact that most the world now works on git. Subversion solves problems with less mental overhead than git, but it's not worth doing anything non-standard, because everyone now knows git and has learned to put up with the worse developer user experience, to the point where people will argue that git doesn't have bad UX, because they've internalised the pain. Before subversion there was CVS and Visual Source Safe. These are much older. These solved a problem of source control, but were based on the concept of locking and modifying files. You'd "checkout" a file, which would lock the file for modification of all other users. It was a bit like using a global locking file repository but with a change history. It was as painful as you might imagine. You'd need to know how to fix the issue where someone would go on holiday having checked out a critical file: https://support.microsoft.com/en-us/topic/5d5fa596-eb9c-d2b5-8af6-faac431283a6 https://support.microsoft.com/en-us/topic/5d5fa596-eb9c-d2b5... Or more routinely, you'd get someone angrily asking who had such-and-such file checked out.
- marcosdumay 2y ago
  CVS was absolutely not oriented around locking files. It was about merge and conflict resolution like SVN or Git. VSS was oriented around locking. And also broke all the time. Oh, and also lost data... And oh, it was also the expensive one used by everybody that kept saying "you get what you pay".
- fanf2 2y ago
  Subversion didn’t get working merge support until years after git. Like CVS it basically required trunk-based development. Feature branches were not supported. You needed a separate checkout for any work in progress. You could not checkpoint your work with a commit before updating to the latest head. Every update is a forced rebase. It sucked.
Cloudef 2y ago
Git is great when you use it from CLI. There is no single good git GUI app. Ideally a GUI git app would give you a interface for rebase and visualize the history, branches and trees. You'd drag commits around and then it would construct a rebase operation for you. In case of conflicts, you can either abort/rollback the operation or open the conflicting files in editor and fix the conflicts. That's it. The github's desktop app in particular is a mess, because it does not try to be a UI, it's simply a frontend for the CLI , having buttons for the CLI operations basically, and it does everything worse than CLI. In hindsight, it's hard for me to take seriously a programmer who can't spend some time to learn git, it isn't hard.

by teqsun 2y ago

vehemenz 2y ago

As an "older" programmer, I feel the opposite. Git became mainstream very recently, though admittedly it's been a good ten years or more. I sometimes think younger programmers' attitudes toward git are borderline cultish—git or GitHub is not required to do programming—it's just another tool. I half expected something would have replaced it by now.

schacon 2y ago
Git's been around for almost 20 years now. I would say fairly dominant for 15 or so.
keybored 2y ago
Git is overrated for a DVCS. But it’s not overrated considering the old-school competition like SVN. The assumptions of SVN makes it feel like a dinosaur now.
- deleted 2y ago
  [deleted]
gmueckl 2y ago
I have to agree on the cult aspect. This is unfortunate because better tools exist already today, but lots of people refuse to even entertain that possibility.
- teqsun 2y ago
  I feel about git how I presume vim users feel. Maybe there are better ways, but I've become so accustomed to how it works that I doubt I could easily switch to anything else.
  - gmueckl 2y ago
    All the more reason to look beyond your comfort zone now and then!
golergka 2y ago
Already in 2010-2012 majority of projects I encountered were using git. Last time I saw an SVN-based project was in 2015, before I migrated it to git.

eterm 2y ago

Subversion (svn) was absolutely fine before git. Before that, there was CVS but that really was painful. Svn gets a lot of hate for things it doesn't deserve, even this article talks about "checking out" and the difficulty of branching, but that doesn't track with subversion. Branching in subversion was just as easy as in git, it had shallow branches. You could branch largely without overhead, although unlike git it was a server-side operation. ( Imagine it like git branch with auto-push to remote). Most software also automatically checked out files as you modified them, and it was a local oepration, there wasn't any locking or contention on that. It was the older CVS/sourcesafe style version system that those. I still maintain that most workplaces with less than, say, 10 devs, would be better off with subversion rather than git, if not for the fact that most the world now works on git. Subversion solves problems with less mental overhead than git, but it's not worth doing anything non-standard, because everyone now knows git and has learned to put up with the worse developer user experience, to the point where people will argue that git doesn't have bad UX, because they've internalised the pain. Before subversion there was CVS and Visual Source Safe. These are much older. These solved a problem of source control, but were based on the concept of locking and modifying files. You'd "checkout" a file, which would lock the file for modification of all other users. It was a bit like using a global locking file repository but with a change history. It was as painful as you might imagine. You'd need to know how to fix the issue where someone would go on holiday having checked out a critical file: https://support.microsoft.com/en-us/topic/5d5fa596-eb9c-d2b5-8af6-faac431283a6 https://support.microsoft.com/en-us/topic/5d5fa596-eb9c-d2b5... Or more routinely, you'd get someone angrily asking who had such-and-such file checked out.

marcosdumay 2y ago
CVS was absolutely not oriented around locking files. It was about merge and conflict resolution like SVN or Git. VSS was oriented around locking. And also broke all the time. Oh, and also lost data... And oh, it was also the expensive one used by everybody that kept saying "you get what you pay".
fanf2 2y ago
Subversion didn’t get working merge support until years after git. Like CVS it basically required trunk-based development. Feature branches were not supported. You needed a separate checkout for any work in progress. You could not checkpoint your work with a commit before updating to the latest head. Every update is a forced rebase. It sucked.

Cloudef 2y ago

Git is great when you use it from CLI. There is no single good git GUI app. Ideally a GUI git app would give you a interface for rebase and visualize the history, branches and trees. You'd drag commits around and then it would construct a rebase operation for you. In case of conflicts, you can either abort/rollback the operation or open the conflicting files in editor and fix the conflicts. That's it. The github's desktop app in particular is a mess, because it does not try to be a UI, it's simply a frontend for the CLI , having buttons for the CLI operations basically, and it does everything worse than CLI. In hindsight, it's hard for me to take seriously a programmer who can't spend some time to learn git, it isn't hard.