8 ms·

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CV

by ken 7y ago

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

dickjocke 7y ago
Can you explain more about that? I've worked with both and I feel like monorepo is kinda a pain, but I dont understand where Git fits in to either directly. Seems like it just snapshots files.
- Skunkleton 7y ago
  In this context "monorepo" means a huge repository with many many revisions. Git has several well documented deficiencies in this scenario. See [1] for microsoft's experiences with git. [1] https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
- chubbyrabbit 7y ago
  It's only a problem at a really large scale. At the scale of Microsoft or Facebook, there are factors that lead to the use of a monorepo being more efficient. At that big of a scale, companies have enough resource to develop internal tooling to deal with the problem (e.g. the use of Mercurial at Facebook).
  - gatekeeperthrow 7y ago
    It would be nice if you and everyone else stopped gatekeeping this problem. We have 600 devs and face these problems. I can assure you we sure as hell dont have the resources spare to reroll git. We're way too busy rerolling everything else.
  - int_19h 7y ago
    FWIW, in case of Microsoft at least, it's more a question of product size than company size. Microsoft doesn't use a single monorepo for everything, like Google (so far as I know) does - just look at http://github.com/microsoft/; http://github.com/microsoft/; and that's not even counting all the VSO repos! It uses product-specific monorepos for some large products.
hn_acc_1 7y ago
I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell
- richardwhiuk 7y ago
  That's true, but it's possible to imagine a system superior to git solving this in someway, in the same way that git solves distributed merges.
- bno1 7y ago
  Maybe it's time for a version control system to come up and fix a problem no one knew they had.
- rhabarba 7y ago
  > I don't see any obvious flaws with Git. Merge conflicts.
  - hn_acc_1 7y ago
    Merge conflicts are not so scary, and are an elegant way to handle distributed changes with simultaneous edits to a single file. If the conflict is huge, rebasing can help you by "playing" the commits from one branch one at a time so the conflicts are smaller / easier to fix. At a previous job, a team was forced to use checkout-style VCS due to their manager's unfounded fear of merge conflicts; I couldn't go in that office without hearing one developer shout to another: "Hey, can you finish up and check in that file so I can get started on my changes?"
    - rhabarba 7y ago
      Sounds like something that would have been solved by using Darcs instead, honestly.
    - hinkley 7y ago
      I’ve spent too much time helping others fix bad merges, and I still catch myself making mistakes. There’s a lot of work that could be done for clarity and error avoidance.
nwallin 7y ago
If I were to pie in the sky dream up a replacement for git, I'd have it store the AST of the parsed code instead of a text file. It would solve a lot of problems with refactoring crapping all over the history. Like I said, pie in the sky. Probably never gonna happen. Personally I don't see git's problems with large binary files and tens of millions of commits as being major issues. Those two alone are way less valuable than git's ecosystem and mindshare.
- randallsquared 7y ago
  It would have to be specific to certain languages, which would, in turn, hinder adoption of new languages to some degree if the git-next took off. So, I'd prefer not to have that be a feature. :)
  - squiggleblaz 7y ago
    I think you could write it as the ability to a diff on a binary ast without fussing too much about what the ast represents. Then you merely need to write a parser/serialiser combo for your language to the ast as a repo plugin. Otherwise it won't just be new languages which suffer, but users of supported languages will suffer when there's an upgrade.
- frutiger 7y ago
  What you want has nothing to do with git (which is a storage model). You can use arbitrary diff and merge resolution algorithms with git's plumbing, which would give you the AST-aware functionality that you want.
  - ken 7y ago
    That's like saying DVCS has nothing to do with VCS -- it's just the server model. Every major advance has been accomplished by increasing the scope of version control. Arbitrary diff/merge in Git is a great example of the Turing Tar-Pit. It's possible, but prohibitively inefficient for many things I want to do. You can't add your own types, index, or query optimizations. Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both.
hinkley 7y ago
I’ve read a couple descriptions of the internals of git that don’t disagree with the design of SVN, so I’m not unsure why you can’t theoretically check out a single subtree. Either the documentation is too hand wavy or some implementation details have blocked that possibility.
- jldugger 7y ago
  Are you aware of git-subtree?
  - hinkley 7y ago
    Git sub tree is the exact opposite of what I’m talking about. Also: > The responsibility of not mixing super and sub-project code in commits lies with you. Is a lie. The responsibility of not mixing code lies with every member of the team. Does the author work alone?
_pmf_ 7y ago
> Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them The successor might very well be git 3.0, though.
dragonwriter 7y ago
> The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy. Isn't that being addressed in Git with the partial clone functionality?

by ken 7y ago

dickjocke 7y ago

Can you explain more about that? I've worked with both and I feel like monorepo is kinda a pain, but I dont understand where Git fits in to either directly. Seems like it just snapshots files.

Skunkleton 7y ago
In this context "monorepo" means a huge repository with many many revisions. Git has several well documented deficiencies in this scenario. See [1] for microsoft's experiences with git. [1] https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
chubbyrabbit 7y ago
It's only a problem at a really large scale. At the scale of Microsoft or Facebook, there are factors that lead to the use of a monorepo being more efficient. At that big of a scale, companies have enough resource to develop internal tooling to deal with the problem (e.g. the use of Mercurial at Facebook).
- gatekeeperthrow 7y ago
  It would be nice if you and everyone else stopped gatekeeping this problem. We have 600 devs and face these problems. I can assure you we sure as hell dont have the resources spare to reroll git. We're way too busy rerolling everything else.
- int_19h 7y ago
  FWIW, in case of Microsoft at least, it's more a question of product size than company size. Microsoft doesn't use a single monorepo for everything, like Google (so far as I know) does - just look at http://github.com/microsoft/; http://github.com/microsoft/; and that's not even counting all the VSO repos! It uses product-specific monorepos for some large products.

hn_acc_1 7y ago

I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell

richardwhiuk 7y ago
That's true, but it's possible to imagine a system superior to git solving this in someway, in the same way that git solves distributed merges.
bno1 7y ago
Maybe it's time for a version control system to come up and fix a problem no one knew they had.
rhabarba 7y ago
> I don't see any obvious flaws with Git. Merge conflicts.
- hn_acc_1 7y ago
  Merge conflicts are not so scary, and are an elegant way to handle distributed changes with simultaneous edits to a single file. If the conflict is huge, rebasing can help you by "playing" the commits from one branch one at a time so the conflicts are smaller / easier to fix. At a previous job, a team was forced to use checkout-style VCS due to their manager's unfounded fear of merge conflicts; I couldn't go in that office without hearing one developer shout to another: "Hey, can you finish up and check in that file so I can get started on my changes?"
  - rhabarba 7y ago
    Sounds like something that would have been solved by using Darcs instead, honestly.
  - hinkley 7y ago
    I’ve spent too much time helping others fix bad merges, and I still catch myself making mistakes. There’s a lot of work that could be done for clarity and error avoidance.

nwallin 7y ago

If I were to pie in the sky dream up a replacement for git, I'd have it store the AST of the parsed code instead of a text file. It would solve a lot of problems with refactoring crapping all over the history. Like I said, pie in the sky. Probably never gonna happen. Personally I don't see git's problems with large binary files and tens of millions of commits as being major issues. Those two alone are way less valuable than git's ecosystem and mindshare.

randallsquared 7y ago
It would have to be specific to certain languages, which would, in turn, hinder adoption of new languages to some degree if the git-next took off. So, I'd prefer not to have that be a feature. :)
- squiggleblaz 7y ago
  I think you could write it as the ability to a diff on a binary ast without fussing too much about what the ast represents. Then you merely need to write a parser/serialiser combo for your language to the ast as a repo plugin. Otherwise it won't just be new languages which suffer, but users of supported languages will suffer when there's an upgrade.
frutiger 7y ago
What you want has nothing to do with git (which is a storage model). You can use arbitrary diff and merge resolution algorithms with git's plumbing, which would give you the AST-aware functionality that you want.
- ken 7y ago
  That's like saying DVCS has nothing to do with VCS -- it's just the server model. Every major advance has been accomplished by increasing the scope of version control. Arbitrary diff/merge in Git is a great example of the Turing Tar-Pit. It's possible, but prohibitively inefficient for many things I want to do. You can't add your own types, index, or query optimizations. Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both.

hinkley 7y ago

I’ve read a couple descriptions of the internals of git that don’t disagree with the design of SVN, so I’m not unsure why you can’t theoretically check out a single subtree. Either the documentation is too hand wavy or some implementation details have blocked that possibility.

jldugger 7y ago
Are you aware of git-subtree?
- hinkley 7y ago
  Git sub tree is the exact opposite of what I’m talking about. Also: > The responsibility of not mixing super and sub-project code in commits lies with you. Is a lie. The responsibility of not mixing code lies with every member of the team. Does the author work alone?

_pmf_ 7y ago

> Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them The successor might very well be git 3.0, though.

dragonwriter 7y ago

> The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy. Isn't that being addressed in Git with the partial clone functionality?