4 ms·

You can either learn the tools of the trade, or you can go online and complain about how your hammer is too hard to use and so you refuse to hold it right. How

You can either learn the tools of the trade, or you can go online and complain about how your hammer is too hard to use and so you refuse to hold it right. How is that not complaining?

maccard 4y ago
That's not a good analogy. A better analogy is someone telling you that you need to understand material sciences to be able to use an impact driver properly.
- counttheforks 4y ago
  Can you learn material sciences in an afternoon of minimal effort?
  - TylerE 4y ago
    No, and neither can one learn git in an afternoon.
    - counttheforks 4y ago
      Speak for yourself.
      - pdimitar 4y ago
        We speak for more than one person and you should stop pretending otherwise. Obviously not everyone can learn it quickly. That's a fact. Denying it is ruining the forum discourse.
  - pdimitar 4y ago
    GIT can't be learned quickly by everyone. I for example haven't needed a graph DB even once throughout a 21 years of career.
  - maccard 4y ago
    No, and you can't learn git in an afternoon either. Here's a very very simple scenario. You and I are working on a fork of a project. You make a branch and push it. I want to update an unrelated branch with the changes from the fork, so I follow [0] (note all of the various adjustments in the comments), and suddenly git switch doesn't work for your branch anymore. Git has dozens of failure modes like this where the behaviour is completely unintuitive unless you understand the internals of git. [0] https://stackoverflow.com/questions/7244321/how-do-i-update-or-sync-a-forked-repository-on-github https://stackoverflow.com/questions/7244321/how-do-i-update-...
    - counttheforks 4y ago
      Not sure what you're going on about. I tried replicating what you describe, but `git switch` keeps working just fine. ~/tmp/foo git init repo1 Initialized empty Git repository in /home/user/tmp/foo/repo1/.git/ ~/tmp/foo cd repo1 tmp/foo/repo1 ‹master› echo hi > hi tmp/foo/repo1 ‹master› git add hi tmp/foo/repo1 ‹master*› git commit -m hi [master (root-commit) d0cf572] hi 1 file changed, 1 insertion(+) create mode 100644 hi tmp/foo/repo1 ‹master› cd .. ~/tmp/foo git clone repo1 repo2 Cloning into 'repo2'... done. ~/tmp/foo cd repo1 tmp/foo/repo1 ‹master› echo hi2 > hi tmp/foo/repo1 ‹master*› git add hi tmp/foo/repo1 ‹master*› git commit -m hi2 [master 3a82bdc] hi2 1 file changed, 1 insertion(+), 1 deletion(-) tmp/foo/repo1 ‹master› git checkout -b someotherbranch Switched to a new branch 'someotherbranch' tmp/foo/repo1 ‹someotherbranch› git tmp/foo/repo1 ‹someotherbranch› echo otherchange > otherchange tmp/foo/repo1 ‹someotherbranch› git add otherchange tmp/foo/repo1 ‹someotherbranch*› git commit -m "otherchange" [someotherbranch 99ec880] otherchange 1 file changed, 1 insertion(+) create mode 100644 otherchange tmp/foo/repo1 ‹someotherbranch› cd ../repo2 tmp/foo/repo2 ‹master› git remote add upstream ../repo1 tmp/foo/repo2 ‹master› git fetch upstream remote: Enumerating objects: 8, done. remote: Counting objects: 100% (8/8), done. remote: Compressing objects: 100% (3/3), done. remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (6/6), 448 bytes | 448.00 KiB/s, done. From ../repo1 * [new branch] master -> upstream/master * [new branch] someotherbranch -> upstream/someotherbranch tmp/foo/repo2 ‹master› git checkout master Already on 'master' Your branch is up to date with 'origin/master'. tmp/foo/repo2 ‹master› git rebase upstream/master Successfully rebased and updated refs/heads/master. tmp/foo/repo2 ‹master› git switch someotherbranch branch 'someotherbranch' set up to track 'upstream/someotherbranch'. Switched to a new branch 'someotherbranch'
bornfreddy 4y ago
Mercurial. Also, not having another option would hardly make git optimal (or even good).
- counttheforks 4y ago
  No, it doesn't. It does make learning it practical considering it's what everyone uses. If you think you can do better, please do! Let me know when you've gotten a few projects to switch over and I'll gladly learn that, too. Not a lot of projects using mercurial these days.
  - capitainenemo 4y ago
    How many projects/companies do you need? There's still a fair number using it.
    - counttheforks 4y ago
      Practically speaking, anything mainstream that I actually use. And the "still" qualifier there is the problem. That number should be growing, not shrinking.
      - capitainenemo 4y ago
        Ok. Mainstream... you use it.. How about: nginx, sudo, pypy, mozilla/firefox, facebook? And. totally agreed, the number should be growing (especially for such a nice piece of tech with a far better toolset). Now that you've signed on to learning, hopefully that will be the case.
TylerE 4y ago
You tell the guy using a brick as hammer that it isn’t actually a good hammer, no matter how many other people are also using bricks as terrible hammers. Git is a brick.
- arcanemachiner 4y ago
  Memories of the "PHP Is A Fractal of Bad Design" article...

You can either learn the tools of the trade, or you can go online and complain about how your hammer is too hard to use and so you refuse to hold it right. How is that not complaining?

maccard 4y ago

That's not a good analogy. A better analogy is someone telling you that you need to understand material sciences to be able to use an impact driver properly.

counttheforks 4y ago
Can you learn material sciences in an afternoon of minimal effort?
- TylerE 4y ago
  No, and neither can one learn git in an afternoon.
  - counttheforks 4y ago
    Speak for yourself.
    - pdimitar 4y ago
      We speak for more than one person and you should stop pretending otherwise. Obviously not everyone can learn it quickly. That's a fact. Denying it is ruining the forum discourse.
- pdimitar 4y ago
  GIT can't be learned quickly by everyone. I for example haven't needed a graph DB even once throughout a 21 years of career.
- maccard 4y ago
  No, and you can't learn git in an afternoon either. Here's a very very simple scenario. You and I are working on a fork of a project. You make a branch and push it. I want to update an unrelated branch with the changes from the fork, so I follow [0] (note all of the various adjustments in the comments), and suddenly git switch doesn't work for your branch anymore. Git has dozens of failure modes like this where the behaviour is completely unintuitive unless you understand the internals of git. [0] https://stackoverflow.com/questions/7244321/how-do-i-update-or-sync-a-forked-repository-on-github https://stackoverflow.com/questions/7244321/how-do-i-update-...
  - counttheforks 4y ago
    Not sure what you're going on about. I tried replicating what you describe, but `git switch` keeps working just fine. ~/tmp/foo git init repo1 Initialized empty Git repository in /home/user/tmp/foo/repo1/.git/ ~/tmp/foo cd repo1 tmp/foo/repo1 ‹master› echo hi > hi tmp/foo/repo1 ‹master› git add hi tmp/foo/repo1 ‹master*› git commit -m hi [master (root-commit) d0cf572] hi 1 file changed, 1 insertion(+) create mode 100644 hi tmp/foo/repo1 ‹master› cd .. ~/tmp/foo git clone repo1 repo2 Cloning into 'repo2'... done. ~/tmp/foo cd repo1 tmp/foo/repo1 ‹master› echo hi2 > hi tmp/foo/repo1 ‹master*› git add hi tmp/foo/repo1 ‹master*› git commit -m hi2 [master 3a82bdc] hi2 1 file changed, 1 insertion(+), 1 deletion(-) tmp/foo/repo1 ‹master› git checkout -b someotherbranch Switched to a new branch 'someotherbranch' tmp/foo/repo1 ‹someotherbranch› git tmp/foo/repo1 ‹someotherbranch› echo otherchange > otherchange tmp/foo/repo1 ‹someotherbranch› git add otherchange tmp/foo/repo1 ‹someotherbranch*› git commit -m "otherchange" [someotherbranch 99ec880] otherchange 1 file changed, 1 insertion(+) create mode 100644 otherchange tmp/foo/repo1 ‹someotherbranch› cd ../repo2 tmp/foo/repo2 ‹master› git remote add upstream ../repo1 tmp/foo/repo2 ‹master› git fetch upstream remote: Enumerating objects: 8, done. remote: Counting objects: 100% (8/8), done. remote: Compressing objects: 100% (3/3), done. remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (6/6), 448 bytes | 448.00 KiB/s, done. From ../repo1 * [new branch] master -> upstream/master * [new branch] someotherbranch -> upstream/someotherbranch tmp/foo/repo2 ‹master› git checkout master Already on 'master' Your branch is up to date with 'origin/master'. tmp/foo/repo2 ‹master› git rebase upstream/master Successfully rebased and updated refs/heads/master. tmp/foo/repo2 ‹master› git switch someotherbranch branch 'someotherbranch' set up to track 'upstream/someotherbranch'. Switched to a new branch 'someotherbranch'

bornfreddy 4y ago

Mercurial. Also, not having another option would hardly make git optimal (or even good).

counttheforks 4y ago
No, it doesn't. It does make learning it practical considering it's what everyone uses. If you think you can do better, please do! Let me know when you've gotten a few projects to switch over and I'll gladly learn that, too. Not a lot of projects using mercurial these days.
- capitainenemo 4y ago
  How many projects/companies do you need? There's still a fair number using it.
  - counttheforks 4y ago
    Practically speaking, anything mainstream that I actually use. And the "still" qualifier there is the problem. That number should be growing, not shrinking.
    - capitainenemo 4y ago
      Ok. Mainstream... you use it.. How about: nginx, sudo, pypy, mozilla/firefox, facebook? And. totally agreed, the number should be growing (especially for such a nice piece of tech with a far better toolset). Now that you've signed on to learning, hopefully that will be the case.

TylerE 4y ago

You tell the guy using a brick as hammer that it isn’t actually a good hammer, no matter how many other people are also using bricks as terrible hammers. Git is a brick.

arcanemachiner 4y ago
Memories of the "PHP Is A Fractal of Bad Design" article...