Obviously not everyone can learn it quickly. That's a fact. Denying it is ruining the forum discourse.
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-...
~/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'Also, not having another option would hardly make git optimal (or even good).
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.
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.
Wanting to understand things before using them is hardly elitism, not sure why you would think that.
Just like you probably don't want to fix bugs without understand the cause, it's hard to use a tool correctly unless you know how the tool works.
Also yeah, I agree learning GIT is not a huge sacrifice but with time I built a huge internal resistance against it so... dunno. ¯\_(ツ)_/¯
Maybe I'll get to it one day, in the meantime I am OK relearning cherry-pick and a few others every time I need them. I don't know, it just doesn't make sense to me. Guess to this day I don't see why it had to be a graph DB.
From the source:
Here’s me being straight up loco and resetting the head of my working tree to a particular commit:
$ git reset --hard 5f1bc85
$ git checkout 5f1bc85
It's not obliterated. It is still in the reflog, and in the history of any other branches or tags then have those commits in their history.
You have to try quite hard or wait 2 months to obliterate something that was committed or stashed into a repo.
You can even recover changes that were only staged.
When I see a doctor, I expect them to be familiar with the latest medical research. I expect they will treat my illnesses with modern medicines and employ the right tools, correctly, and understand how they work at a sufficient level of depth to do the job correctly. For example, I used to make electrical medical staplers; surgeons need not care about how RTOSes work, but they need to know how to interact with the software enough to do their job. Similarly, I'm not saying we all ought to be able to build Git from scratch. I'm saying we ought to master it to the extent necessary. If your use case is committing alone on a single branch, learn "git commit". But for most devs, understanding the tree structure that Git uses to store data and what basic operations are doing "under the covers" builds a mental model that makes Git easy.
We have to have the time to learn the tools that help us do our jobs well. You can neglect that duty to do "real work", as much as a doctor can neglect learning how to use a scalpel so they can "get on with the surgery".
Even when the tools themselves suck?
The thing about our profession is that anyone can build better tools. Just like Linus took a week or two to sketch Git with some C code and a bunch of shell scripts (seriously, that was what happened - but he had the BitKeeper design in mind and how to improve on it). There is not regulation that says that in order to build a tool for millions of people to use you need to have a certification or anything.
Citing it as if it's something that's even needed to be said is kind of ironic on a forum with mostly programmers in it who, I am pretty sure, by and large possess a fair amount of critical thinking and quick analysis skills.
A ton of people have to make do with partial schedules. And I mean a ton, likely no less than 85% of all programmers everywhere.
You might want to make a good deep analysis on whether you're not coming from a position of severe privilege and a very positive filter bubble.
Conflating the two, like you do, is elitism.
"If you just stopped and read to understand...", a-ha, sure, I'll do that for every one of the no less than 500 tools I've used over the course of my career and will never get anything done on time.
There's no time. We got real work to do and no we can't switch to a company that gives us this time. There's a big world outside the Silicon Valley.
GIT is a huge UX failure and seeing people pretend otherwise makes me question my -- or their -- sanity.