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.

deleted by creator

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.

https://git-scm.com/docs/git-gui/

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”.

Git is ugly and functional.

I don’t even think it’s ugly. It just works and is intuitive if you bother to understand what you’re doing.

I think some vocal critics are just expressing frustration they don’t “get” a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first “why” they come across, they start to blame the tool.

Git is no different. But it sure feels like it never took the idea of a polished user experience seriously.

I’ve seen this sort of opinion surface often,but it never comes with specific examples. This takes away from the credibility of any of these claims.

Can you provide a single example that you feel illustrates the roughest aspect of Git’s user experience?

Edit: just noticed this post is over 10 years old.

It would be helpful if the title was edited to feature the release date. Context is king. So many things are absurd with regards to the current state, but are sorely lacking a few years ago.

This shape certainly beats a triangle (…)

Nature loves triangles.

https://en.wikipedia.org/wiki/Michell_structures

Highly recommended

I agree. Once we get a hang of the value that bisect brings, one unintended consequence is that we start to value atomic commits a whole lot more. There is nothing more annoying than bisecting a bug and suddenly stumbling upon a commit that does it all: updates dependencies, touches everything under the sun, does cleanup commits for unrelated files, etc. Yuck.

“GitUI is amazing, although unusable.”

So is it just Amazon getting hit for this? Or will they be going after the manufacturer as well?

Nowadays it’s hard to tell the difference between Amazon and Ali Express. Even if it’s a third-party dropship business selling through Amazon, it’s still Amazon doing the listing, selling, and transaction processing.

Even if you argue that the same store can sell stuff elsewhere, Amazon is still the one selling those. At best, you’d need to argue that after hitting Amazon, other stores should follow.

As a followup to this post, I’ve started including git rebase -i in my workflow when working on local branches. Basically things went like this:

• I start working on an issue in a dedicated feature branch.
• I commit small changes such as “Updates this feature in this component”, “fixes this glitch on this function”, “removes this dead code”.
• I keep going until I’m done.
• If I stumble upon small nits, I just commit them right at the head.
• when I’m done I run an interactive rebase and move these small commits around to sort commits that belong together.
  • nits and followup fixes are squashed together,
  • cleanup commits are moved to the start of the branch to line them up to be pushed as a separate pull request,
  • push a PR for the issue

To me this really paves a way to a far better workflow and faster turnaround times.

I don’t think you mean ‘merge’ - that’s a specific operation. I think you mean ‘squash’, which combines multiple commits into one.

Yes, you are right. I apologize for the terminology mixup. I was referring to how it’s possible to join two changesets so that they can be considered in the commit history as a single commit.

Once you get familiar with rebasing, you could try out stacked git.

Thanks for the recommendation, but I’ll take a pass. Vanilla Git does the job well.

appears to be a weak patch.

It’s not a patch. It’s eliminating an attack vector, and the one which is more pervasive and easier to exploit.

Security-minded people pay far more attention to what software you run than what hardware you have.

But we often hear about ‘corporate lobbying’ and you’ve described things mostly carried out by individuals or nonprofits.

No, I’m describing lobbying. The definition of lobbying doesn’t depend on your market capitalization or revenue. A corporation does lobbying, just like unions do and industry representatives and community groups. If you have personal interests and want to raise awareness with stakeholders then you reach out to them.

I mean, Wikipedia’s article on lobbying also refers to it as advocacy. From Wikipedia;

In politics, lobbying or advocacy, is the act of lawfully attempting to influence the actions, policies, or decisions of government officials, most often legislators or members of regulatory agencies, but also judges of the judiciary.

“Attempting to influence” is the operative principle.

And so is “lawfully”. Which is not the same as the corruption you pinned on “Eastern countries”.