I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the “distributed” mindset didn’t happen overnight.
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. It got easier when I eventually realized that git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.
git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space
Yeah, once you realize that everything falls into place.
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.
That other people would care as much for a clean history like I do. Specifically, opening branches and leaving them open forever without merging them back into main, many useless commits rather than squashing or amending, or making branches-of-branches-of-branches. Drives me nuts
Omg so this. Also merging main branches into feature branches instead of rebasing.
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.
Instead of a commit history, you get a commit fairy tale, which is prettier than the truth, but probably less useful. You get something akin to merging the base branch into the feature branch but things look as if they were done in an order they weren’t instead of getting an ‘ugly’ merge commit.
In many providers it’s possible to set up an automatic squash policy when merging to main. At our company the git history is just linear with well defined commits.
I don’t think this is necessarily better. Some branches/projects are big enough that there are meaningful commits that should be made inside the project.
Yeah I agree but in my experience developers seem to struggle with “keep important things in history; squash unimportant things”. An open “merges allowed” policy leads to people unthinkingly merging branches with 50 “typo”, “fix” commits for a 100 line change.
Dunno what the answer is there.
I guess it’s dependent on project, but IMO if a commit is important enough to be in the main branch, then that should have its own merge request. I like it when all commits in the main branch have gone through all the build pipelines and verification processes.
But if having separate MRs is undesirable, then you could always overrule the squash policy. I know it’s possible on Gitlab at least.
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”.
There are no strict rules for how you should use git, it’s just a tool, with some guidelines what would probably work best in certain scenarios. And it’s fine diverge from those guidelines, add or remove some extra steps depending on what kinda project or team-structure you’re working in.
If you’re new to Git, you probably shouldn’t just lookup Gitflow, structure your branches like that, and stick strictly to it. It’s gonna be a bit of trial-and-error and altering the flow to create a setup that works best
At that point you might as well add an alias that does all these three things.
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.
Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used “gitflow” as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.
But there’s nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you’re using it and it seems more practical to adapt the flow for your own use-case, don’t worry it’d be considered wrong to not stick strictly to it
That given its popularity it would be more user friendly. Every good dev tool will have its internals or more advanced features. Git is no different. But it sure feels like it never took the idea of a polished user experience seriously. Which is fine. It’s a dev tool after all. But the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.
the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.
I don’t think this is true.
Git is ugly and functional.
People love to complain about it being ugly, but it does what it’s meant to. If there was actually a persistent productivity hit from its interface, one of the weird wrappers would have taken off, and replaced it.
But the truth is, those wrappers all seem to be written by people learning to use git in the first place, and just get abandoned once they get used to it.
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.
there has to have been a significant global productivity cost due to the lack of a better UI.
I’m not so sure about this to be honest. If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.
If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.
As I said in another reply … how many GUIs and text editor plugins are there for git and how many use them?
What other CLI tool has as much work put into GUIs, wrappers and plugins that do not try to replace the underlying tool/CLI, even accounting for popularity?
There is no other CLI tool like Git. But
Shell or Bash has various alternative shells.
Vim has numerous plugins and alternatives/extensions.
Linux distributions are wide and varied, forking out.
Probably important to remember that Git was designed by Linus Torvalds, the same dude who developed the Linux kernel, and who is infamous for going off on big rage-fueled rants when questioned about his methods. So yeah, it’s going to be clunky and obtuse.
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?
Yeah sure. git push says “did you mean git push -u branchname origin”. Yes obviously I meant that. I always mean that.
I’d been copying and pasting that for about 5 years before I discovered there’s a feature (auto branch setup or something) which means it will automatically do that. But it’s not mentioned in the error message! Why?
Git has a load of --fixed-behaviour flags like that that are just not on by default and never mentioned.
The terminology is very poorly chosen in a lot of cases. “The index”? Wtf is that? “Staging area” is at least slightly better but would “draft commit” have been too much to ask? Ours/theirs is also a stonkingly bad choice of words. How does Git know which code is mine? It doesn’t. Hell it isn’t even consistent about which way around they are.
Someone has force pushed a branch and I want to update my local ref (without typing the whole branch name again). git pull gives a wall of text without the answer, which is… git reset --hard @{u}. Catchy!
Or maybe I’ve got a branch that is tracking my fork but I want to pull from upstream. Can I do git pull upstream? Nope. I have to repeat the branch name git pull upstream branch-i-am-on. (Please don’t say "but git doesn’t know which branch you want to pull.)
Then there’s the error messages… Make a branch called foo/bar. Now try to check out a remote branch foo. See that nice explanation about how git branches are actually files and directories, not just strings? Nope? Huh.
This is just a few I can remember off the top of my head but it’s the tip of the iceberg.
yea this all generally tracks.
The kind of “polish” I’m talking about is the sort that a good UI/UX/GUI dev would do by tracking common user behaviours and needs or having testing users run the app through its paces. All of these confusing instances where better terminology, commands and error messages would come up through a process like that.
Now, one could say that this is a dev tool which shouldn’t need to go through that process. That developers should be expected to understand the tool’s inner workings and conceptual model well enough to not need any of that. But that gets back to my initial point. Git is so popular and basically ubiquitous now that that policy makes little sense. Many devs who use or are expected to use git are not capable of getting to terms with git’s internals to the point of never having difficulty with the UI, either because of a lack of time, capacity or skill. Moreover, the time required to get familiar with git enough to never find the UI frustrating should not be underestimated … it’s not just conceptual but technical and specific to git’s implementation details to the point of just knowing how the UI/CLI has been implemented.
If you want to trash such developers … go ahead … but they’re still developer’s doing work and it’s to the industry’s benefit to have a standardised and powerful VCS … which means that at some point it’s worth thinking about meeting developers where they are.
Beyond all of that … one could also say “fuck that” and talk about how being popular and “the standard” requires being better. Git’s centrality to the dev workflow as at text-editor levels. But while text editors have a portable format (IE “plain text” and character encodings) and so enjoy pretty healthy competition (vim, emacs, sublime, VSCode, Jetbrains … etc) … VCSs, AFAICT, don’t have the same portability and neither the competition. I’m actually curious now … are there drop in replacements for git that provide complete compatibility but are completely different implementations?.
It’s interesting, IMO, to think about why/how this has come to be, but in the end, it means that there’s a lot on git’s shoulders here. Even a little bit of an improvement can go a long way, and so being critical (rather than cultishly defensive), I’d argue, is the correct aspect here on utilitarian grounds.
As for why git is in its current situation (without having really thought about it before) … I’d actually speculate that there’s something insidious here regarding it’s imperfect/confusing UI. Namely that it has a monopolising force. Once it’s gained critical mass, and once there are enough devs out there who have deep and experienced understanding of the tool, and enough internet content capturing that expertise, then moving off to another tool which doesn’t have the same established expertise is prohibitively difficult. Comparing here VCS to text editing and programming languages may be part of it, where the basic difficulty of doing VCS (at least in so far as the complexity is exposed to the user) is likely somewhere between that of a text-editor and a programming language. In a similar vein, the solution space for VCSs is probably relatively small while text-editors and languages enjoy a good deal of design variety. And so, there’s little interest or inventive or even capacity to come up with interesting alternatives for what is a relatively difficult/complex kind of tool, which gives any established VCS a good amount of competitive protection and inertia.
Keep in mind though, I’m not talking about the UI here, but the core functionality. That many GUIs exist shows that the UI is a relatively open design space. But that git itself has hardly explored that space on their own is my critique (where comparing to text editors like vim/nvim and emacs and the built-in features they have might be informative here).
I mean sure. I personally haven’t researched and become an expert on this … it is an early-user’s misconceptions thread after all. And a dev can justifiably reflect on all of their tooling and consider their general usability against their popularity.
However, by the same token, your lack of any counter examples isn’t exactly highly credible either.
Nonetheless:
- Whenever I’ve seen an opinion from someone who’s used both mercurial and git, their opinion is always that the mercurial interface and model “actually makes sense”
- AFAICT, the git CLI (at least up until the more recent changes) has widely been recognised as being unnecessarily janky and confusing especially for common and basic tasks
- Apart from that, many devs have shared that they always struggle to remember git commands and always need to rely on some reference/cheat-sheet (obligatory XKCD), which IMO is a product of it both having a poor CLI in need of polish and being a program/tool that isn’t naturally constrained to CLI usage but rather naturally implemented with a graphical of some sort.
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’s internals are very easy to understand and once you know more about them, you’ll have a much better idea of how it works (especially when it comes to tags and branches). They’re so simple, you could even easily write your own scripts to parse git’s internal data directory if you wanted to.
I would highly recommend reading about them: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#
