4 ms·

We say this now, ignoring the hot messes that were SourceSafe, Pervasive, CVS, and SVN. Git is light years more elegant that predecessors, and its holding power

We say this now, ignoring the hot messes that were SourceSafe, Pervasive, CVS, and SVN. Git is light years more elegant that predecessors, and its holding power is evidence of that. We're able to criticize now because we've had the privilege of forgetting (or never having experienced) just how bad it used to be, and the sheer amount of time with one tool that's been a staple for far longer than previous tools lasted.

unclebucknasty 5y ago
Most of the previous version control systems you mentioned were much less complex and had an extraordinadily easy mental model to understand in comparison. Git set out to solve a different problem: adapt VCS to an agile, CI/CD world. It does this much better than those previous VCS generations, but its mental model does seem needlessly complex.
- nijave 5y ago
  Well, I think it was also meant to be highly distributed as well (many different people all over the place could then come back and bring their changes together) In order to achieve that, I think you end up with some additional complexity like local vs remote and a complicated graph structure to accommodate people coming "on" and "off" line
  - unclebucknasty 5y ago
    >Well, I think it was also meant to be highly distributed as well Yeah, I guess I kind of consider that an agile tenet: in general, that people can work quickly and iteratively with limited interdependencies. Said another way, it would be difficult for teams to work in an agile fashion--where the work itself is frequently distributed and happening in parallel--using most older VCS models.
- plorkyeran 5y ago
  Git set out to solve the problems the Linux kernel development faced, which is not particularly "Agile" and doesn't do CI/CD.
  - unclebucknasty 5y ago
    Point taken. May be more accurate to say that it solves some core common challenges that made it attractive for those later use cases. Main point being that comparing the complexity of Git and, say, SVN isn't apples to apples, as the former is suited to use cases that are inherently more complex.
  - B1FF_PSUVM 5y ago
    > Git set out to solve the problems the Linux kernel development faced Which were "send patches to the maintainer", and a little bit of "work offline". Linus fixed those as needed, and people who haven't those problems are using his solution a bit like painful fashionable shoes - they hurt but dagnabbit, that's what the fashion is ...
notacoward 5y ago
I've used RCS, SCCS, CVS, Subversion, SourceSafe, ClearCase, AccuRev, Perforce, and probably at least one more I've forgotten. ClearCase was a garbage fire for reasons of performance and stability, but none of them had an internal model that was as much of a hot mess as git's. It's not the OP who has forgotten what things used to be like. Maybe you-now understands git better than you-then understood CVS (for example), but that might have more to do with personal learning curves than with inherent complexity.
- mbfg 5y ago
  clearcase, lock the branch, go on vacation. yeah good model. And then there's the multisite replication mess. Maybe they fixed that in the 20 years since i used it.. but that was a disaster.
- fiddlerwoaroof 5y ago
  Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated.
  - bombcar 5y ago
    Arguably a big part of the confusion around the internal model is that git half-hearted pretends it’s actually just a pile of patches.
  - tablespoon 5y ago
    >> but none of them had an internal model that was as much of a hot mess as git's. > Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated. I'll do you one better: it's just some byte arrays on disk. I think the OP has a section that gets at some of the complexity of git's model: > The complexity of Git distracts attention from the software under development. A user of Git needs to keep all of the following in mind: > a. The working directory > b. The "index" or staging area > c. The local head > d. The local copy of the remote head > e. The actual remote head > Git has commands (and/or options on commands) for moving and comparing content between all of these locations.
bluGill 5y ago
I used mercurial for years before being forced to use git, and historically hg came first (by only a few weeks, but still first)
marricks 5y ago
Certainly, but those other systems stuck around a while after GIT was around because people possibly thought SVN/etc were as good as it gets. That said, Mercurial and Fossil came out within a year of GIT so GIT at least outcompeted them early on.
- jcranmer 5y ago
  > That said, Mercurial and Fossil came out within a year of GIT so GIT at least outcompeted them early on. Git, Mercurial, and Bazaar all came out within three weeks of each other (late March/early April 2005).
sergiotapia 5y ago
Bullshit - Git won because it was incredibly easy to clone a project and have all it's history there _and_ you could work on stuff offline seamlessly. You could git commit things without working internet.

unclebucknasty 5y ago

Most of the previous version control systems you mentioned were much less complex and had an extraordinadily easy mental model to understand in comparison. Git set out to solve a different problem: adapt VCS to an agile, CI/CD world. It does this much better than those previous VCS generations, but its mental model does seem needlessly complex.

nijave 5y ago
Well, I think it was also meant to be highly distributed as well (many different people all over the place could then come back and bring their changes together) In order to achieve that, I think you end up with some additional complexity like local vs remote and a complicated graph structure to accommodate people coming "on" and "off" line
- unclebucknasty 5y ago
  >Well, I think it was also meant to be highly distributed as well Yeah, I guess I kind of consider that an agile tenet: in general, that people can work quickly and iteratively with limited interdependencies. Said another way, it would be difficult for teams to work in an agile fashion--where the work itself is frequently distributed and happening in parallel--using most older VCS models.
plorkyeran 5y ago
Git set out to solve the problems the Linux kernel development faced, which is not particularly "Agile" and doesn't do CI/CD.
- unclebucknasty 5y ago
  Point taken. May be more accurate to say that it solves some core common challenges that made it attractive for those later use cases. Main point being that comparing the complexity of Git and, say, SVN isn't apples to apples, as the former is suited to use cases that are inherently more complex.
- B1FF_PSUVM 5y ago
  > Git set out to solve the problems the Linux kernel development faced Which were "send patches to the maintainer", and a little bit of "work offline". Linus fixed those as needed, and people who haven't those problems are using his solution a bit like painful fashionable shoes - they hurt but dagnabbit, that's what the fashion is ...

notacoward 5y ago

I've used RCS, SCCS, CVS, Subversion, SourceSafe, ClearCase, AccuRev, Perforce, and probably at least one more I've forgotten. ClearCase was a garbage fire for reasons of performance and stability, but none of them had an internal model that was as much of a hot mess as git's. It's not the OP who has forgotten what things used to be like. Maybe you-now understands git better than you-then understood CVS (for example), but that might have more to do with personal learning curves than with inherent complexity.

mbfg 5y ago
clearcase, lock the branch, go on vacation. yeah good model. And then there's the multisite replication mess. Maybe they fixed that in the 20 years since i used it.. but that was a disaster.
fiddlerwoaroof 5y ago
Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated.
- bombcar 5y ago
  Arguably a big part of the confusion around the internal model is that git half-hearted pretends it’s actually just a pile of patches.
- tablespoon 5y ago
  >> but none of them had an internal model that was as much of a hot mess as git's. > Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated. I'll do you one better: it's just some byte arrays on disk. I think the OP has a section that gets at some of the complexity of git's model: > The complexity of Git distracts attention from the software under development. A user of Git needs to keep all of the following in mind: > a. The working directory > b. The "index" or staging area > c. The local head > d. The local copy of the remote head > e. The actual remote head > Git has commands (and/or options on commands) for moving and comparing content between all of these locations.

bluGill 5y ago

I used mercurial for years before being forced to use git, and historically hg came first (by only a few weeks, but still first)

marricks 5y ago

Certainly, but those other systems stuck around a while after GIT was around because people possibly thought SVN/etc were as good as it gets. That said, Mercurial and Fossil came out within a year of GIT so GIT at least outcompeted them early on.

jcranmer 5y ago
> That said, Mercurial and Fossil came out within a year of GIT so GIT at least outcompeted them early on. Git, Mercurial, and Bazaar all came out within three weeks of each other (late March/early April 2005).

sergiotapia 5y ago

Bullshit - Git won because it was incredibly easy to clone a project and have all it's history there _and_ you could work on stuff offline seamlessly. You could git commit things without working internet.