DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Is Git Great? #healthydebate

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 (32)

Collapse
natescode profile image
Nathan Hedglin

GIT is British slang for "dumb". I too after a decade feel dumb using GIT.

GIT is good but it has a lot of rough edges, showing it hasn't aged well.

Git has a horrible API and terrible defaults. Finally, you can configure GIT to push the remote without explicitly saying --set-upstream-branch.

Git assumes you're commonly using multiple remotes and naming local branches differently locally.

Still a million times better than TFVC .

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author

I did felt dumb every time I tried to use git submodules.

Collapse
natescode profile image
Nathan Hedglin

because you shouldn't use them, seriously lol. I've found one case where they worked ok.

Thread Thread
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author

You meant you never found one case or you have found only one?

Thread Thread
natescode profile image
Nathan Hedglin

I found one. For submodule for CMS editor code that basically never changes and is deployed separately.

Submodules the concept are great but GITs implementation is really poor.

Thread Thread
ecyrbe profile image
ecyrbe

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.

Thread Thread
natescode profile image
Nathan Hedglin

Great thanks for expanding. I'll look into the Deno method. I may be wrong 😊.

Thread Thread
unsungnovelty profile image
Nikhil

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 --remote to 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.

Thread Thread
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author

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.

Thread Thread
unsungnovelty profile image
Nikhil

Doesn't Hugo have a theme repository where you can publish your stuff?

My theme is not open source. And a lot of themes tells you to add the theme as gitsubmodule anyways.

Thread Thread
natescode profile image
Nathan Hedglin

Sounds like the right way to do it to me.

Collapse
bradtaniguchi profile image
Brad • Edited on

git ultimately 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, git does its job really well, and the alternatives have too many pitfalls to be considered seriously. Because of that, git has become the choice, for better or worse.

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author • Edited on

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.

Collapse
natescode profile image
Nathan Hedglin

Very well said. Hence why I have SO many GIT aliases lol.

Collapse
crisoncode profile image
Cristian Estarlich • Edited on

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.

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author • Edited on

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.

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.

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

Collapse
crisoncode profile image
Cristian Estarlich

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.

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.

In fact, correcting people is overrated

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.

Thread Thread
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author

You can make git simpler by

  • taking a subset of it (forget submodules, rebase, ...)
  • use the pull request instead of the commit as the unit of work
  • use a good GUI tool - personally I use IntelliJ because I don't care about the staging area, I want auto-fetch, I don't want to have to type branch names, I want to see the diffs in my editor, ...
Collapse
simplegeek profile image
SimpleGeek

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

Collapse
michelemauro profile image
michelemauro

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.

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author

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?

Collapse
ecyrbe profile image
ecyrbe • Edited on

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 :

  • git branch are just a reference to a commit (called light branches/ bookmarks in mercurial), where as in mercurial your branch and your commit are glued together with a name (called heavy/named branches). This has some impacts i'll explain below...
  • git allows to change remote history, whereas in mercurial you can only change your local history...
  • mercurial named branches, comes with what is called phases that are status attached to your local version of your branch and for example allows for good rebase defaults. it's impossible in mercurial to rebase in the wrong order (rebase remote on your local), you can only rebase your local to your remote. this evoids rooky mistakes on rebase commands.
  • there is no stagging area in mercurial, so if you want to only add a part of a file to your next commit, you have to use tools like interactive commits.
  • there is no patch system in mercurial, but you have a plugin called queues that are a mix of patches and stash. It's definitely easier to understand for new users than the patch system of git.
Thread Thread
michelemauro profile image
michelemauro

Also:

  • there is a bundle file format, that can carry around commits and branch names safely between repositories (in fact, I used it to collaborate before BitBucket was there). This file format enables me to collect the homeworks from my students with the certainty that they will not be able to mess up with my repository. I'm not sure if that can be done in git with the same level of peace of mind.

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.

Collapse
michelemauro profile image
michelemauro

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.

Thread Thread
nstvnsn profile image
Nathan Stevenson

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.

Thread Thread
michelemauro profile image
michelemauro

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.

Collapse
jessekphillips profile image
Jesse Phillips

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.

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.

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author • Edited on

Document version control sucks. Git is intended for programs, natural language and rules do not operate the same.

Here we agree.

Git is a communication tool
I do spend a lot using git to craft my changes.

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.

Collapse
jessekphillips profile image
Jesse Phillips

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 provides every line with a comment about its existence, this is something not provided by other tools, only support it.

Thread Thread
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ Author • Edited on

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

Collapse
dgrabla profile image
David Grajal

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.

Collapse
michelemauro profile image
michelemauro

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.

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.