6 ms·

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics,

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

PawBer 4y ago
You can treat the points in the article as those.
spencerchubb 4y ago
that's what the whole rest of the article is about :)
bergenty 4y ago
I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the version control system should be doing.
- oivey 4y ago
  I’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.
- samtheprogram 4y ago
  These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method. Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if you try to push to a more up to date upstream.
  - bergenty 4y ago
    There shouldn’t be different ways to handle the same problem. It should literally be 4 features and call it a day. Simplicity is a feature.
- gspr 4y ago
  With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.
  - dotancohen 4y ago
    > And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.
    - oivey 4y ago
      Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?
      - CuriousCosmic 4y ago
        Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge. Some projects prefer rebasing onto master instead of merging onto master or squashing onto master. If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place. If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested. If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.
- Akronymus 4y ago
  I use stashes all the time, when I realize I am working on the wrong branch.
  - dreamcompiler 4y ago
    Stashes seem very mysterious to many people. They're one of the most sensible parts of git IMHO. They're just a stack of changes to your files. To me, rebases are the work of the devil and I never use them. To each their own I guess.
    - Akronymus 4y ago
      > Stashes seem very mysterious to many people. Huh. For me, they were one of the most intuitive parts of git. Altough, it was a long time before I ever used more than 1 layer of stash at once. (And even then, I rarely do so nowadays)
    - mariusor 4y ago
      Personally I never understood why the stash needs to be a stack. I can't think of a time when the order in which changes have been stashed has mattered, outside of dropping the older ones.
- thunderbong 4y ago
  You should give Fossil a shot https://fossil-scm.org https://fossil-scm.org
oconnore 4y ago
Perhaps, instead of trying to identify issues with git, think about how really deep team based collaboration works in other programs (say, online video games?) and then work backwards to see if there are opportunities in code collaboration tools. Of course, just making an IDE multi-player would introduce chaos. What if the tool solved that chaos?
- gpderetta 4y ago
  of course there are multiple emacs packages for that :) : https://www.emacswiki.org/emacs/CollaborativeEditing https://www.emacswiki.org/emacs/CollaborativeEditing
nine_k 4y ago
On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pijul. - Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code. Don't get me wrong: the data structures and ideas on which git is based are beautiful and reliable. But something (even) better can be built on these ideas.
- 5e92cb50239222b 4y ago
  > Git is slow on large repos, even on an SSD. Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.
  - nine_k 4y ago
    How about `git status`? The first SSD I bought back in 2008 was to put a large git repo on it; it helped. With much larger repos, like those I had to work with at Facebook, even an NVMe drive becomes a bit uncomfortable, and one has to use something like Watchman [1] to track changes without a rather noticeable delay. [1]: https://github.com/facebook/watchman https://github.com/facebook/watchman
    - Akronymus 4y ago
      maybe this is of interest to you? https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/ https://github.blog/2022-06-29-improve-git-monorepo-performa...
    - glandium 4y ago
      FWIW, see https://news.ycombinator.com/item?id=31928844 https://news.ycombinator.com/item?id=31928844
drewcoo 4y ago
Yes. I am also asking "for a friend!"

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

PawBer 4y ago

You can treat the points in the article as those.

spencerchubb 4y ago

that's what the whole rest of the article is about :)

bergenty 4y ago

I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the version control system should be doing.

oivey 4y ago
I’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.
samtheprogram 4y ago
These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method. Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if you try to push to a more up to date upstream.
- bergenty 4y ago
  There shouldn’t be different ways to handle the same problem. It should literally be 4 features and call it a day. Simplicity is a feature.
gspr 4y ago
With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.
- dotancohen 4y ago
  > And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.
  - oivey 4y ago
    Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?
    - CuriousCosmic 4y ago
      Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge. Some projects prefer rebasing onto master instead of merging onto master or squashing onto master. If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place. If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested. If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.
Akronymus 4y ago
I use stashes all the time, when I realize I am working on the wrong branch.
- dreamcompiler 4y ago
  Stashes seem very mysterious to many people. They're one of the most sensible parts of git IMHO. They're just a stack of changes to your files. To me, rebases are the work of the devil and I never use them. To each their own I guess.
  - Akronymus 4y ago
    > Stashes seem very mysterious to many people. Huh. For me, they were one of the most intuitive parts of git. Altough, it was a long time before I ever used more than 1 layer of stash at once. (And even then, I rarely do so nowadays)
  - mariusor 4y ago
    Personally I never understood why the stash needs to be a stack. I can't think of a time when the order in which changes have been stashed has mattered, outside of dropping the older ones.
thunderbong 4y ago
You should give Fossil a shot https://fossil-scm.org https://fossil-scm.org

oconnore 4y ago

Perhaps, instead of trying to identify issues with git, think about how really deep team based collaboration works in other programs (say, online video games?) and then work backwards to see if there are opportunities in code collaboration tools. Of course, just making an IDE multi-player would introduce chaos. What if the tool solved that chaos?

gpderetta 4y ago
of course there are multiple emacs packages for that :) : https://www.emacswiki.org/emacs/CollaborativeEditing https://www.emacswiki.org/emacs/CollaborativeEditing

nine_k 4y ago

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pijul. - Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code. Don't get me wrong: the data structures and ideas on which git is based are beautiful and reliable. But something (even) better can be built on these ideas.

5e92cb50239222b 4y ago
> Git is slow on large repos, even on an SSD. Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.
- nine_k 4y ago
  How about `git status`? The first SSD I bought back in 2008 was to put a large git repo on it; it helped. With much larger repos, like those I had to work with at Facebook, even an NVMe drive becomes a bit uncomfortable, and one has to use something like Watchman [1] to track changes without a rather noticeable delay. [1]: https://github.com/facebook/watchman https://github.com/facebook/watchman
  - Akronymus 4y ago
    maybe this is of interest to you? https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/ https://github.blog/2022-06-29-improve-git-monorepo-performa...
  - glandium 4y ago
    FWIW, see https://news.ycombinator.com/item?id=31928844 https://news.ycombinator.com/item?id=31928844

drewcoo 4y ago

Yes. I am also asking "for a friend!"