6 ms·

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,

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.
- thenewnewguy 7y ago
  Merge conflicts are a part of any VCS that allows two people to edit the same file at the same time.
  - HALtheWise 7y ago
    However, in some cases (like non-mergeable binary files), it is actually better to have a system that allows one user to take a lock on a file and have exclusive editing abilities. The git protocol has no support for those workflows, and so people end up using a Google Doc or something to track who is modifying what file. Definately a place for improvement.
    - shakna 7y ago
      How do you lock a file in a distributed system? Many people won't be online. Many people won't be on the exact same head.
      - squiggleblaz 7y ago
        > Many people won't be on the exact same head. This consideration is actually irrelevant to locking non-mergeable binary files. It doesn't matter what branch we're on or where the file is located, only that you and I both want to edit the logo. Eventually, either your version must be based on mine, or mine based on yours, since they will be merged. So it's probably better not to have that file in Git, since it doesn't support the workflow around which Git is based. It's actually right to store your design documents in Google Docs or a wiki and your code in Git, rather than everything in Git. It is easy to have one filestore to rule them all and in the darkness bind them, but if you want to do different things with them, you have to do different things with them. I'm not sure that it's possible to unify text file and binary doc based workflows, but it seems we don't have to worry because users automatically use the best tool for the job and it's only hackers who tie themselves in knots trying to make git do everything.
- james_s_tayler 7y ago
  No VCS will be merge conflict-less without locking files. I'd rather not lock files.
  - deleted 7y ago
    [deleted]
  - ben509 7y ago
    I'd rather lock files, but be able to unlock them, to be able to coordinate with others and proactively reduce merge conflicts.
    - wyoung2 7y ago
      The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS. I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences. We discussed this deeply on the Fossil forum: https://www.fossil-scm.org/forum/forumpost/2afc32b1ab https://www.fossil-scm.org/forum/forumpost/2afc32b1ab We came to no easy answers, because there aren't any. You only get a choice of which problems to accept.
      - ben509 7y ago
        I'm talking about purely advisory locks. Accessing a locked file would let you know who locked it, and if you unlock it, it would just notify them. So it's just a communications mechanism in addition to regular merges. The alternate method is that locking a file marks you as an interested party to a merge, allowing you to review the correctness of a merge. This would be purely to avoid changes being lost during merges.
- jamil7 7y ago
  I've worked in teams where developers seemed terrified of merge conflicts, to the point of telling eachother not to edit a particular file which seems absurd. Maybe I don't know any better but they seem like part of life.
  - int_19h 7y ago
    When at least one person is making changes that touch large parts of the file, it's very sensible to ask others to not touch it, if you don't want to spend hours merging it manually later.
jayd16 7y ago
>I don't see any obvious flaws with Git. Large files and long histories hinder its total dominance in the game and art industries. Because of git's shortcomings polyrepo is a near necessity not simply a stylistic choice. LFS is a bolt on solution that could/should have better support.
- phodge 7y ago
  > Because of git's shortcomings polyrepo is a near necessity I'm intrigued by this claim. I've come to the opposite conclusion - that monorepo is near necessity with git because there's no tools for branching/rebasing multiple repos at once.
  - bb88 7y ago
    I think he's talking about large files there, which is an issue in GIT btw. I would use it for storing and syncing libraries of large images for my photography, if it were feasible.
  - thayne 7y ago
    After using both I can say both have problems. Polyrepos lack tools for working with multiple repos simultaneously, and require more attention to versioning. Monorepos have longer histories, and the large number of objects can hurt performance. Which one you should use depends on which downsides are less impactful for your use case.
- hinkley 7y ago
  Git stores the diffs in chronological order doesn’t it? I recall reading about someone doing a commercial implementation where the commits are stored in reverse chronological order. I’d been thinking that was github but I’ve never been able to find the article again.
  - fjfaase 7y ago
    Git does not store differences between files, but packs (versions of) files (to save disk space) in single .pack files.
smt88 7y ago
Git is extremely user-unfriendly from the command line. It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.
- jack_h 7y ago
  > It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space. In my opinion this is a problem with programming languages rather than version control. Namely we mix presentation and representation when using text as our source code. In the case of whitespace we have an infinite number of syntactic presentations which all correspond to the same semantic representation. Tooling has been created to try to deal with this such as code formatters which canonicalize the syntactic presentation for other tools. Git itself even has to deal with this because of platform differences, i.e. LF and CRLF.
  - deleted 7y ago
    [deleted]
  - smt88 7y ago
    > Git itself even has to deal with this because of platform differences, i.e. LF and CRLF. I loathe this about git. It has caused my team members so many problems, like images marked as changed. git should either be dumb about content or smart, not secretly in between.
- Kwantuum 7y ago
  I don't think that's true. I've been using git's CLI since I started using git a few years ago, and exactly zero of my problems with git could've been solved by a different user interface (be it GUI or a "better" designed CLI). Pretty much all of my problems have been with my lacking understanding of the abstractions that git uses to make all of the powerful things it can do possible.
  - Supermancho 7y ago
    > I don't think that's true. You are in the minority. It's such a ubiquitous experience, a running joke in the industry. Saying a tool is useful and powerful, is fine and good. That sentiment has nothing to do with usability.
dilap 7y ago
cherry picking is a shitshow! i would love to be able to use a patch-based VC.
- james_s_tayler 7y ago
  You can still generate and apply patches with Git.
  - nemo1618 7y ago
    I believe GP is referring to Darcs/Pijul-style patches, rather than Git "patches," which are really just diffs. See https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...
  - dilap 7y ago
    yep, nemo got it right. git basically hacks cherry-picks in the same way previous VCS’s hacked branches. unfortunately there are no patch-theory based VCS’s with a practical level of usability. what git was to monotone, X is to darcs/pijul, where X hasn’t been created yet.
ken 7y ago
Yes -- that's what it means to be a flaw with the entire current generation of version control systems. "Need a centralized server" wasn't specific to one (pre-DVCS) system, either.
bhaak 7y ago
How about history tracking for file renames doesn't work well? It's hit and miss if git blame --follow works. Subversion did this better even before Git existed. Git is completely oblivious to moving code from one file to another. Git blame will never show you the original commit if you just relocated a method to another file. Due to this, refactoring often put additional hurdles into exploring the code history.
matheusmoreira 7y ago
Git submodules have lots of problems. I wanted it to work like a symbolic link to another repository so that I could develop both at the same time on the same machine. Just like how pip allows me to install a Python package in editable mode. If I make a change in the submodule, the superproject should automatically see it.

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.
thenewnewguy 7y ago
Merge conflicts are a part of any VCS that allows two people to edit the same file at the same time.
- HALtheWise 7y ago
  However, in some cases (like non-mergeable binary files), it is actually better to have a system that allows one user to take a lock on a file and have exclusive editing abilities. The git protocol has no support for those workflows, and so people end up using a Google Doc or something to track who is modifying what file. Definately a place for improvement.
  - shakna 7y ago
    How do you lock a file in a distributed system? Many people won't be online. Many people won't be on the exact same head.
    - squiggleblaz 7y ago
      > Many people won't be on the exact same head. This consideration is actually irrelevant to locking non-mergeable binary files. It doesn't matter what branch we're on or where the file is located, only that you and I both want to edit the logo. Eventually, either your version must be based on mine, or mine based on yours, since they will be merged. So it's probably better not to have that file in Git, since it doesn't support the workflow around which Git is based. It's actually right to store your design documents in Google Docs or a wiki and your code in Git, rather than everything in Git. It is easy to have one filestore to rule them all and in the darkness bind them, but if you want to do different things with them, you have to do different things with them. I'm not sure that it's possible to unify text file and binary doc based workflows, but it seems we don't have to worry because users automatically use the best tool for the job and it's only hackers who tie themselves in knots trying to make git do everything.
james_s_tayler 7y ago
No VCS will be merge conflict-less without locking files. I'd rather not lock files.
- deleted 7y ago
  [deleted]
- ben509 7y ago
  I'd rather lock files, but be able to unlock them, to be able to coordinate with others and proactively reduce merge conflicts.
  - wyoung2 7y ago
    The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS. I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences. We discussed this deeply on the Fossil forum: https://www.fossil-scm.org/forum/forumpost/2afc32b1ab https://www.fossil-scm.org/forum/forumpost/2afc32b1ab We came to no easy answers, because there aren't any. You only get a choice of which problems to accept.
    - ben509 7y ago
      I'm talking about purely advisory locks. Accessing a locked file would let you know who locked it, and if you unlock it, it would just notify them. So it's just a communications mechanism in addition to regular merges. The alternate method is that locking a file marks you as an interested party to a merge, allowing you to review the correctness of a merge. This would be purely to avoid changes being lost during merges.
jamil7 7y ago
I've worked in teams where developers seemed terrified of merge conflicts, to the point of telling eachother not to edit a particular file which seems absurd. Maybe I don't know any better but they seem like part of life.
- int_19h 7y ago
  When at least one person is making changes that touch large parts of the file, it's very sensible to ask others to not touch it, if you don't want to spend hours merging it manually later.

jayd16 7y ago

>I don't see any obvious flaws with Git. Large files and long histories hinder its total dominance in the game and art industries. Because of git's shortcomings polyrepo is a near necessity not simply a stylistic choice. LFS is a bolt on solution that could/should have better support.

phodge 7y ago
> Because of git's shortcomings polyrepo is a near necessity I'm intrigued by this claim. I've come to the opposite conclusion - that monorepo is near necessity with git because there's no tools for branching/rebasing multiple repos at once.
- bb88 7y ago
  I think he's talking about large files there, which is an issue in GIT btw. I would use it for storing and syncing libraries of large images for my photography, if it were feasible.
- thayne 7y ago
  After using both I can say both have problems. Polyrepos lack tools for working with multiple repos simultaneously, and require more attention to versioning. Monorepos have longer histories, and the large number of objects can hurt performance. Which one you should use depends on which downsides are less impactful for your use case.
hinkley 7y ago
Git stores the diffs in chronological order doesn’t it? I recall reading about someone doing a commercial implementation where the commits are stored in reverse chronological order. I’d been thinking that was github but I’ve never been able to find the article again.
- fjfaase 7y ago
  Git does not store differences between files, but packs (versions of) files (to save disk space) in single .pack files.

smt88 7y ago

Git is extremely user-unfriendly from the command line. It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.

jack_h 7y ago
> It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space. In my opinion this is a problem with programming languages rather than version control. Namely we mix presentation and representation when using text as our source code. In the case of whitespace we have an infinite number of syntactic presentations which all correspond to the same semantic representation. Tooling has been created to try to deal with this such as code formatters which canonicalize the syntactic presentation for other tools. Git itself even has to deal with this because of platform differences, i.e. LF and CRLF.
- deleted 7y ago
  [deleted]
- smt88 7y ago
  > Git itself even has to deal with this because of platform differences, i.e. LF and CRLF. I loathe this about git. It has caused my team members so many problems, like images marked as changed. git should either be dumb about content or smart, not secretly in between.
Kwantuum 7y ago
I don't think that's true. I've been using git's CLI since I started using git a few years ago, and exactly zero of my problems with git could've been solved by a different user interface (be it GUI or a "better" designed CLI). Pretty much all of my problems have been with my lacking understanding of the abstractions that git uses to make all of the powerful things it can do possible.
- Supermancho 7y ago
  > I don't think that's true. You are in the minority. It's such a ubiquitous experience, a running joke in the industry. Saying a tool is useful and powerful, is fine and good. That sentiment has nothing to do with usability.

dilap 7y ago

cherry picking is a shitshow! i would love to be able to use a patch-based VC.

james_s_tayler 7y ago
You can still generate and apply patches with Git.
- nemo1618 7y ago
  I believe GP is referring to Darcs/Pijul-style patches, rather than Git "patches," which are really just diffs. See https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...
- dilap 7y ago
  yep, nemo got it right. git basically hacks cherry-picks in the same way previous VCS’s hacked branches. unfortunately there are no patch-theory based VCS’s with a practical level of usability. what git was to monotone, X is to darcs/pijul, where X hasn’t been created yet.

ken 7y ago

Yes -- that's what it means to be a flaw with the entire current generation of version control systems. "Need a centralized server" wasn't specific to one (pre-DVCS) system, either.

bhaak 7y ago

How about history tracking for file renames doesn't work well? It's hit and miss if git blame --follow works. Subversion did this better even before Git existed. Git is completely oblivious to moving code from one file to another. Git blame will never show you the original commit if you just relocated a method to another file. Due to this, refactoring often put additional hurdles into exploring the code history.

matheusmoreira 7y ago

Git submodules have lots of problems. I wanted it to work like a symbolic link to another repository so that I could develop both at the same time on the same machine. Just like how pip allows me to install a Python package in editable mode. If I make a change in the submodule, the superproject should automatically see it.