7 ms·

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

by vvpan 2y ago

stephen_g 2y ago
I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.
- riffraff 2y ago
  Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning. Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs. Compare git diff with hg diff for example.
  - account42 2y ago
    I've never been confused by git checkout. git checkout <branch> switches to a branch. git checkout <commit> switches to a commit in a detached head state. git checkout <file> switches just the content of a file. You can also combine these ofc but it all works pretty much as expected. The -b switch for creating new branches is someting you need to look up once and then just remember - and it does make sense - you are switching to a new branch.
    - riffraff 2y ago
      I've dealt with people who are new to git and the fact that "git checkout X" does one thing or another based on what X is, was confusing for them, even if I could find an explanation for it. If you didn't have the same experience, good for you! But compare "git switch X" and "git restore X". This makes different things look different, and obvious, which is usually a valuable thing when learning a new tool.
  - imcritic 2y ago
    Git is wrong in some regards: they introduce an entity "branch", but it is not stored properly, it's like virtual data. The proof that there are really no branches in git's storage is a simple task that's not achievable in git: suppose you had some branch, but you don't remember it's name, then you branched off and issued some commits. Now there's no way to get a git history consisting of just the commits introduced since you branched off.
- crabbone 2y ago
  Nope. It was initially built for the use-case most people will never have: multiple remotes that work on a project with multiple similar products each with its own set of differences from the others, with emphasis and dependency on Unix tools and text-only emails. Most Git users will never have more than one remote per project, and so will only have a single product built from their source code. Probably wouldn't even know how to configure their mua to send text-only emails, in case that option is even available to them, and would struggle with basic Unix utilities like Vim and diff. I don't know why Git won the VCS contest. But, I'm afraid, as with many such wins, there wasn't a clear rational reason why it should have won. It didn't make some of the obvious bad decisions which would disqualify it, but so did a few others. My take on this is that communication tools naturally gravitate towards monopoly, so, if one starts to win even slightly, the win will become a landslide win.
  - maccard 2y ago
    > I don't know why Git won the VCS contest Because GitHub offered free git hosting, and heroku came along and offered free hosting that was pretty much point and go. Combined, you all of a sudden went from needing a sysadmin and two servers (this was pre containers), and the sysadmjn skills to operate SVN and your web app, to “it’s now free and it auto deploys when I commit”.
    - crabbone 2y ago
      Bitbucket offered free Mercurial hosting before GitHub even existed, if memory serves. And it's all but dead. And, I don't know if GitHub succeeded because of Git or the other way around.
      - maccard 2y ago
        This war was over around about the time I started, but my take on it is that it's all a bit intermixed and Mercurial lost because bitbucket caved and did git hosting [2], but git won beacuse of github and heroku [1][2] [1] https://www.koyeb.com/blog/herokus-free-tier-legacy-the-shoulders-we-stand-on-15-years-later https://www.koyeb.com/blog/herokus-free-tier-legacy-the-shou... [2] https://blog.gitbutler.com/why-github-actually-won/ https://blog.gitbutler.com/why-github-actually-won/
Barrin92 2y ago
No. Git is a complex program but version control is an inherently complex problem that requires powerful tools. There's certain set of problems where, as a programmer, you're going to have to sit down and actually read the book. The universe doesn't owe you an easy 10 minute video solution to everything, it's an annoying educational expectation that people seem to have developed. Some things are just that difficult and you have to learn them regardless.
- forrestthewoods 2y ago
  No. Source control is not that complicated. Git is just bad. As an existence proof: Mercurial is much better and simpler. I can teach someone who has never even heard of source control how to use Perforce in about 10 minutes. They will never shoot themselves in the foot and they will never lose work. There are certainly more advanced techniques that require additional training. But the basics are very easy. Git makes even basic things difficult. And allows even experts to shoot their face off with a rocket launcher. Git sucks. The best tool doesn't always win. If MercurialHub had been founded instead of GitHub we'd all be used a different tool. Alas.
  - beej71 2y ago
    Out of curiosity, what are the most common foot guns, in your opinion?
    - lostdog 2y ago
      Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.
      - rblatz 2y ago
        Find your last entry before the rebase using the reflog and reset your local branch to that entry. The work isn’t lost, it is sitting right there.
mbonnet 2y ago
git can suck, but it's the best tool we've got for the job.

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

by vvpan 2y ago

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.

riffraff 2y ago
Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning. Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs. Compare git diff with hg diff for example.
- account42 2y ago
  I've never been confused by git checkout. git checkout <branch> switches to a branch. git checkout <commit> switches to a commit in a detached head state. git checkout <file> switches just the content of a file. You can also combine these ofc but it all works pretty much as expected. The -b switch for creating new branches is someting you need to look up once and then just remember - and it does make sense - you are switching to a new branch.
  - riffraff 2y ago
    I've dealt with people who are new to git and the fact that "git checkout X" does one thing or another based on what X is, was confusing for them, even if I could find an explanation for it. If you didn't have the same experience, good for you! But compare "git switch X" and "git restore X". This makes different things look different, and obvious, which is usually a valuable thing when learning a new tool.
- imcritic 2y ago
  Git is wrong in some regards: they introduce an entity "branch", but it is not stored properly, it's like virtual data. The proof that there are really no branches in git's storage is a simple task that's not achievable in git: suppose you had some branch, but you don't remember it's name, then you branched off and issued some commits. Now there's no way to get a git history consisting of just the commits introduced since you branched off.
crabbone 2y ago
Nope. It was initially built for the use-case most people will never have: multiple remotes that work on a project with multiple similar products each with its own set of differences from the others, with emphasis and dependency on Unix tools and text-only emails. Most Git users will never have more than one remote per project, and so will only have a single product built from their source code. Probably wouldn't even know how to configure their mua to send text-only emails, in case that option is even available to them, and would struggle with basic Unix utilities like Vim and diff. I don't know why Git won the VCS contest. But, I'm afraid, as with many such wins, there wasn't a clear rational reason why it should have won. It didn't make some of the obvious bad decisions which would disqualify it, but so did a few others. My take on this is that communication tools naturally gravitate towards monopoly, so, if one starts to win even slightly, the win will become a landslide win.
- maccard 2y ago
  > I don't know why Git won the VCS contest Because GitHub offered free git hosting, and heroku came along and offered free hosting that was pretty much point and go. Combined, you all of a sudden went from needing a sysadmin and two servers (this was pre containers), and the sysadmjn skills to operate SVN and your web app, to “it’s now free and it auto deploys when I commit”.
  - crabbone 2y ago
    Bitbucket offered free Mercurial hosting before GitHub even existed, if memory serves. And it's all but dead. And, I don't know if GitHub succeeded because of Git or the other way around.
    - maccard 2y ago
      This war was over around about the time I started, but my take on it is that it's all a bit intermixed and Mercurial lost because bitbucket caved and did git hosting [2], but git won beacuse of github and heroku [1][2] [1] https://www.koyeb.com/blog/herokus-free-tier-legacy-the-shoulders-we-stand-on-15-years-later https://www.koyeb.com/blog/herokus-free-tier-legacy-the-shou... [2] https://blog.gitbutler.com/why-github-actually-won/ https://blog.gitbutler.com/why-github-actually-won/

Barrin92 2y ago

No. Git is a complex program but version control is an inherently complex problem that requires powerful tools. There's certain set of problems where, as a programmer, you're going to have to sit down and actually read the book. The universe doesn't owe you an easy 10 minute video solution to everything, it's an annoying educational expectation that people seem to have developed. Some things are just that difficult and you have to learn them regardless.

forrestthewoods 2y ago
No. Source control is not that complicated. Git is just bad. As an existence proof: Mercurial is much better and simpler. I can teach someone who has never even heard of source control how to use Perforce in about 10 minutes. They will never shoot themselves in the foot and they will never lose work. There are certainly more advanced techniques that require additional training. But the basics are very easy. Git makes even basic things difficult. And allows even experts to shoot their face off with a rocket launcher. Git sucks. The best tool doesn't always win. If MercurialHub had been founded instead of GitHub we'd all be used a different tool. Alas.
- beej71 2y ago
  Out of curiosity, what are the most common foot guns, in your opinion?
  - lostdog 2y ago
    Messing up conflicts during a rebase, thinking I did it right, and then finalizing the rebase and losing work that accidentally disappeared. That's my most common mistake at least.
    - rblatz 2y ago
      Find your last entry before the rebase using the reflog and reset your local branch to that entry. The work isn’t lost, it is sitting right there.

mbonnet 2y ago

git can suck, but it's the best tool we've got for the job.