Git is ubiquitous in our developing world, but is it OK to talk about the trade-offs?
Some things I have noticed:
- poor learning curve. Really, it's usable mostly because of GitHub/GitLab
- even after 10+ years using it, I consistently hear that I'm using it wrong, that I should git-rebase stuff, follow the conventions for git commit messages, branches, etc... Can't we relax about so-called "best practices" and focus on the task at hand?
- too many features that often get in the way. The mark of a great tool is that it's so good at doing its job that you can forget about it. On the other hand, I feel that we are spending a disproportionate amount of attention and energy baby-sitting git.
- documentation mostly useless because to accomplish something, you have to know already what command you need to use. On the other hand, that's a gold mine for content creators. So many common tasks need a translation in plain English.
- git is horrible for certain use cases like managing technical documentation. I'm positive that if Wikipedia had been powered by git, it would have plateaued at 10,000 articles today instead of 10,000,000
- more importantly, a macho culture has formed around git where if you use a GUI or don't understand something, it's not because it's poorly explained in the documentation, or too complex, or has a poor UX. Nope, it's simply because you are too mediocre a programmer. I imagine that's a logical legacy from Linus Torvalds, who would have probably responded in a public email that if you don't get something, it's because you are too stupid. That's a convenient way of not addressing the issues.
What are your thoughts?
Top comments (26)
gitultimately falls to the same issue as to why not everyone is a Linux user. Both systems are built on the idea that there should be lots of small tools that handle 1 thing.The issue with this sort of design system is lack of abstraction. Us developers can easily be the type that "wants the control", so systems built with lots of smaller tools that together handle large amounts of use-cases with minimal or no abstraction seems appealing in theory.
However, in practice it means needing to understand a lot of tools/features just to perform simple tasks that should or could be straight forward with an abstraction.
Ultimately there comes a time where there is a "better tool" that abstracts away most of the underlying complexity. However,
gitdoes its job really well, and the alternatives have too many pitfalls to be considered seriously. Because of that,githas become the choice, for better or worse.The design principle from Alan Key is that Simple things should be simple, complex things should be possible.
There is a mentality common to Linux and git (started by the same guy...) that you start by the second half and the first half with somehow sort itself out.
Nope.
Hmm. Maybe I am doing it wrong. I deploy my Hugo theme as a submodule in my Hugo website. This way my friend can use the theme as well and all they have to do is
git submodule update --rebase --remoteto update my theme. The main advantage being my friend can't make changes and mess it up which are possible if he clone my theme repo to his website.Doesn't Hugo have a theme repository where you can publish your stuff? seems more sane than messing with git submodules. Same for sharing code. Maven is better at that.
My theme is not open source. And a lot of themes tells you to add the theme as gitsubmodule anyways.
IMO the problem within GIT is the lack of educationΒΏ? (at least here in Spain).
When you're studying software development (I don't mind if it's on a degree, bootcamp, whatever) the only thing that the teachers are explaining is how to make a commit and how to create branches.
The other things (a huge list of features) are not explained and you're learning it in your journey as a Developer, I can compare it with the learning of an human language:
If you're learning it by your own probably you will start to make mistakes and nobody will say it to you then you're creating "bad habits".
In any case, very nice discussion! I started to work with git when I became a dev so I don't have experience with other versioning tools.
If git was better designed with better defaults you would need less education time to learn it. Education is supposed to teach you the concepts, not the quirks of any particular tool. Which will change all the time.
In fact, correcting people is overrated. It's almost always better to the person speak more and practice his new language. It's better to infer what is the correct way of speaking by hearing to the responses of the person you are talking with.
Only if you are making often the same mistake would I make you pause and correct you.
I'm thinking about how we can make a tool like git more simple, I mean, it's not easy... GIT is a super complex tool, maybe we can have a kind of "git lite" with less features and simplified commands in the CLI?
I'm not sure.
I'm with you, but in some cases we need to teach people when they are making mistakes. When we're learning software development we're learning a lot of things at same time therefore it's totally normal to create bad habits and so on.
You can make git simpler by
This. Very much this. Git is a hugely important part of my daily development workflow in my job now, but I received no training on it whatsoever while studying for my degree (studied in America).
You are prefectly right. And coming to git after 10+ years in Mercurial heaven, it took me a while to learn git's quirks.
It's another VHS-vs-Betamax thing.
That's interesting, I wondered how mercurial compares.
Do you have examples of common use cases that are straightforward in Mercurial heaven and quircky in git?
Branches is the biggest difference. The "branch is a property of the commit" model of mercurial is much, much easier to understand compared to the "branch is the label of the graph head". The resulting workflow is simpler and less error-prone, especially for the newbies.
Command names and ergonomy is much higher in mercurial, since it was deliberately thought and chosen. Git was written in a hurry because there was a need (Linus parted ways with the sponsor of the previous kernel's VCS) and focused on functionality in Linus' terms.
Collaborating without a central server is very easy: just bundle your changes and share them on Skype (well, I used to do like that some 15 yrs ago). There is no way you can mess up a coworker's repo: it's very difficoult to break an hg repository.
By enforcing pull request to branch head only, enforcing reviews, no one is going to break my repo unless I press the big red "Do Not Push" button myself. That said, hg does sound like it would be a nice experience.
I'll be sticking with git for its ubiquity and GitHub's integration with...everything lol. I will, however, try out Mercurial when free time permits. I am more than a bit curious.
The sad state of the affairs is that, after losing the JDK, that was one of the last "high profile" repositories that still used mercurial, I think it is sliding (not even slowly) towards irrelevance.
It is very very unlikely that the "gitops" ecosystem will care to add an option for the source repository tool. It will, however, become a problem sometime in the future; when it happens, a replacement will probably need to be something far for modern and robust even than Mercurial.
An interesting candidate for this role is Pijul. It has a well thought theory behind it, a quite good execution (that is, is dogfooding a log), and a hard look back at the history of the VCS toolset. With a heavy heart, I suggest you that your valuable free time will be better spent experimenting with that.
I'll continue to use mercurial in my university classes, to expose the students to something good.
I also used Mercurial for a long time. It has all the same mindset, that everything is decentralized and your local repository can synchronise with a remote one. It also uses acyclic graph to represent your history.
To sumarize key diffs :
Also:
And as for the rebase thing, there was a solution in the works a few years ago: I don't know now if it has been deployed.
The staging area is maybe the only thing in git that I find remotely useful, sometimes. But I went on for years without it, and sometimes it just gets in the way.
I find that people don't view programming as crafting changes. Sure people will work towards a feature change or bug fix, but getting there can be more than just changing it.
Git is a Communication tool
Jesse Phillips γ» Dec 12 '18 γ» 2 min read
I don't spend my time babysitting git, but I do spend a lot using git to craft my changes. This process helps me build a better end result as I can reaffirm the changes made.
GUI tools make git way more complicated, well some of them. I use a hybrid approach, but I utilize gitk to help me visualize portions of the tree. When trying to use other gui tool I can know what I want to do, but the GUI isn't clear I'll get that result.
Document version control sucks. Git is intended for programs, natural language and rules do not operate the same. That said I think you can tell git how to diff different file types.
Here we agree.
I guess my question would be if that's really the best communication tool you have at your disposal and the energy you spend rewriting your git history would not be better spent elsewhere.
It seems to me that Pull Requests are much better ways to discuss things, and you can squash the end result and be done with it.
If there are issues left to be addressed, the issue tracker seems a better way to do it.
If your commit messages contain important notes for your colleagues, they should probably moved to your internal Wiki where they can be more easily found and udpated later.
For the users and new contributors of your projects, good communication is done via a good README, your blog posts describing it and the documentation website.
So yes, if you had unlimited time and energy, it's better to have a nice git history than a messy one.
But in real life we don't and I would argue that git communication is less important than all the others I cited.
I work in a distributed environment. Clients get custom builds with unique integrations. So my time spent is very much benefits the needs to distribute changes.
Git and Other Communication Tools
Jesse Phillips γ» Jan 9 '19 γ» 1 min read
Git provides every line with a comment about its existence, this is something not provided by other tools, only support it.
Why was this bug introduced?
Jesse Phillips γ» Jan 11 '19 γ» 1 min read
I am happy to hear that such fine grained effort is worth it in your context.
In general I think all "best practices" exist because they proved to be useful to some people, enough so that they made the effort to write and talk about it. The issue arise when you see some cool technique that proved useful for Facebook or Google, and an inexperienced team adopt it without reflecting on whether it has the same main pain points than Facebook or Google.
TL:DR it always depends on the context
Git is SO SO SO much better than what we had before. Do you remember cvs? subversion? Uff that was painful. It appeared at the correct time and it expanded quickly because it was the most popular free tool at the time. As with car driving, It is easy to start using it but difficult to master, but you don't really need to master it to be proficient with it.
You obviously never tried mercurial, or some of the other options like Darcs.
Yes, CVS was painful. I still have SVN repos where I work, and I try to stay as away from them as I can (helped migrating some of them to git). But Git is no saviour, and there are much better options out there.
I did felt dumb every time I tried to use git submodules.
You meant you never found one case or you have found only one?
I do not agree with nathan here.
I use submodules heavily on some projects.
The issue with submodules is that people do not understand how to handle it. Submodules are just references to your git submodule HEAD at the time of commit of your parent module.
Do not try to commit submodules HEAD on your parent repository when you push commits on your submodules. it makes no sense, you'll waste time and effort for nothing.
Just commit your submodules HEAD on parent repository when you add or remove new submodules. Or when you want to tag a global new version of your project.
You can take a look at submodules done right on deno project.