std::unordered_map is one of the worst ones
It should be noted that the benchmark focused on the std::unordered_map implementation from GCC 13.2.0. I'm not sure if/how this conclusion can be extended to other implementations such as msvc or clang.
What is the advantage of rebasing?
You get a cleaner history that removes noise from the run-of-the-mill commit auditing process. When you audit the history of a repo and you look into a feature branch, you do not care if in the middle of the work a developer merged with x or y branch. What you care about is what changes were made into mainline.
3
Technical Standard - Distributed Transaction Processing: The XA Specification (PDF)
(www.opengroup.org)
Because this is a casual discussion and that’d be more effort than I’m willing to put in.
I didn't asked you to write a research paper. You accused Git of suffering from usability issues and I asked you to provide concrete examples.
And apparently that's an impossible task for you.
If you cannot come up with a single example and instead write a wall of text on you cannot put the effort to even provide a single opinion... What does this say about your claims?
I think nobody talks about it because it doesn’t show history
What do you mean it doesn't show history? It's perhaps the only thing it handles better than most third-party git GUIs.
It’s not and no one cares about numbers anymore.
The only people who ever cared about svn's numbering scheme were those who abused it as a proxy to release/build versions, which was blaming the tools for the problems they created for themselves.
I initially found git a bit confusing because I was familiar with mercurial first, where a “branch” is basically an attribute of a commit and every commit exists on exactly one branch.
To be fair, Mercurial has some poor design choices which leads to a very different mental model of how things are expected to operate in Git. For starters, basic features such as stashing local changes were an afterthought that you had to install a plugin to serve as a stopgap solution.
think the lack of UI
Even git ships with git-ui. It's not great, but just goes to show how well informed and valid your criticism is.
Sure if you never branch, which is a severely limited way of using git.
It's quite possible to use Git without creating branches. Services like GitHub can automatically create feature branches for you as part of their ticket-management workflow. With those tools, you start to work on a ticket, you fetch the repo, and a fancy branch is already there for you to use.
You also don't merge branches because that happens when you click on a button on a PR.
I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.
I don't think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it's a trait of Git is like complaining that Java is hard because you need to use camelCase.
Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.
Nonetheless
You didn't provided a single concrete example of something you actually feel could be improved.
The most concrete complain you could come up was struggling with remembering commands, again without providing any concrete example or specific.
Why is it so hard for critics to actually point out a specific example of something they feel could be improved? It's always "I've heard someone say that x".
I've been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.
The main factors in burning out we're always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It's not Agile's fault that your manager wants a feature out in half the time while looming dismissals over your head.
It's not Agile's fault that stack ranking developers results in hostile team environments where team members don't help out people and even go as far as putting roadblocks elsewhere so that they aren't the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.