Things I just don't like about Git

https://cohost.org/tef/post/3009746-things-i-just-don-t

by todsacerdoti • 3 years ago

56 116 3 years ago

I love these posts. I bookmark all of them.

I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.)

I'd love to hear more about what people hate about Git.

hotnfresh2• 3 years ago

I'd love to hear more about what people hate about Git.

It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common—suck a lot more than it needs to.

gavinhoward8• 3 years ago

Good to know. I'll make mine a library and tool, like SQLite.

rascul• 3 years ago

Have you looked into libgit2?

https://libgit2.org/

miohtama3• 3 years ago

Back in a day, late 00s, early 10s, Git had alternatives.

- Bazaar

- Mercurial (Hg)

Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible.

What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user interface. Early days, Github itself had a lot of competition. Bitbucket (now Atlassian) was the same but for Mercurial. However, Github, as a good American startup, won over the world, popularising Git along the way.

(Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)

Qwertious• 3 years ago

BitBucket no longer supports Mercurial, only Git.

Thankfully, SourceHut does support Mercurial (and, IIRC, it also supports Fossil).

jamseason• 3 years ago

Both had superior user experience compared to git

Highly subjective.

Both Mercurial and Bazaar were plagued a long time by muddled branching and collaboration story. In hg there were the anonymous branches, multiple repos, bookmarks, all worked in different ways and their interactions were confusing. Bazaar I didn't use much but remember not understanding at all its branching model then, and didn't bother finding out.

Git won because it got many things right from the start, and was better than the competition.

Izkata• 3 years ago

Back then, when I had only subversion experience, I tried both git and mercurial, and found mercurial really confusing. Ended up using git for everything, the way it worked just made sense to me.

Unfortunately it's been long enough that I don't remember any details about why I found mercurial confusing.

sgbeal5• 3 years ago

(Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)

Back in 2011 or 2012 i once had one of the libgit developers sitting at my workstation for a full hour trying un-hose my local checkout after i'd made the mistake of following git instructions from SO.

SO git advice: 0 of 5 stars. Cannot recommend.

CableNinja3• 3 years ago

git gained popularity way before github/gitlab. Its popularity stemmed from the features that CVS and SVN were severely lacking. Github just made it easier to share and discover projects, and it happened to use git. It also helps that github was not a target for foss, instead it was started as a business. Before then, git, cvs, svn, were all foss projects and hosted (usually mostly) by the project owners.

domador2• 3 years ago

I wish I lived in an alternate timeline where a delightfully unpronounceable service called HgHub had won the day instead. But on a more open-minded note, would Github been just as successful if they had used something other than Git for the backend? Or was Git already popular enough that Github had essentially no other choice but to use it instead of another DVCS if they wanted to become the dominant player in their space?

fouc4• 3 years ago

I was using git before github was even a thing. Ruby on Rails community was already moving to git in 2006 & 2007. Github was created by a couple of Rails developers that saw the popularity of git and responded.

I also tried Darcs, Bazaar & Mercurial back then. Those options were slooowww. Git largely won because it was blazing fast, and easy to understand. Probably having the cachet of Linus helped. I personally found transitioning from svn to git was a breeze.

I do have some quibbles about the structure of commands & arguments from an UX perspective with git, but ultimately it wasn't a dealbreaker.

codetrotter• 3 years ago

Will your VCS be compatible with git pull, git push, and the file format on disk used by git?

gavinhoward8• 3 years ago

No. I'll be using SQLite and weave files in order to handle massive amounts of data (terabytes or more) while having full transactions.

IshKebab• 3 years ago

Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git.

In a very large project you can have a monorepo, and then everything is slow and you can't easily use and work on a subset of the code.

Or you can use submodules and then testing, refactoring and making commits all become a nightmare.

Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.

I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.

gavinhoward8• 3 years ago

Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git.

As a lone developer, I admit that this is what surprises me the most about the experience of other people.

But I'm going to solve it. Partial checkouts, fully-transactional cross-submodule commits, the works.

Really, these problems are easy with a good design. It's unfortunate that Linus didn't have time for design.

Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.

Yeah, I don't get this either.

I am implementing a general plugin system for creating format-aware operations. This will include source code and binary files.

I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.

I fully agree. I'm going to the doing UX studies, and that's my first priority.

I am going to handle conflict resolution better, though.

domador2• 3 years ago

Many years ago, when I was looking for a worthy DVCS successor to Subversion for my single-developer projects (just in case they became multiple-developer projects), I evaluated Git, Bazaar, and Mercurial. I don't really remember what were the deciding factors, but I ended up going with Mercurial. I'm sure usability was a big part of it, since that's a major value for me, and I really didn't like git in that department. I think I also read some things that made me distrust git's handling of data, but don't remember the specifics. git just seems messy in other ways as well. I still wonder to this day whether the wrong DVCS won the popularity contest and became an unfortunate default option for developers.

UweSchmidt4• 3 years ago

Scrap the thing entirely and replace it with something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Folders instead of branches. Be 100% language-aware; any merge result has to build obviously.

If this rejects actions and limits possibilities that Git provides, so be it.

gavinhoward8• 3 years ago

I agree. You laid out my current design in a nutshell, actually. Except for folders. But my branches will be more than a bookmark.

fanf26• 3 years ago

I think folders instead of branches is a mistake, because folders are a tree but branches are a graph.

fiedzia2• 3 years ago

You will immediately find that people use version control differently and "undo" means different things for them, therefore you have either: a) 50 variants of "undo" b) one official undo, but "here we use git foo" because reasons c) people operating directly on the repo structure because a) and b) are to complicated and broken for some specific workflow. d) most likely - mix of all those options. What I don't get is why people insist on using git directly. Define your workflow and create aliases named "undo", "save" etc. that work with folders instead of branches if you wish, call it our_git and use it. I've seen people do something like that.

wetpaws• 3 years ago

"git is made from papercuts"

This pretty much summarises my experience with git.

miohtama3• 3 years ago

Git is what a software version control would look like if it were created by kernel devs who only knew C and Perl.

fiedzia2• 3 years ago

True. However this mix of C and Perl works. I remember early days of git and whenever someone tried to bring Mercurial (or something else), the answer for any non-trivial "how do I do X" in git was "here are some magic commands" and the answer from mercurial guys was "oh... you can't, the plugin for that doesn't exist yet". And that's how git won (well, it was also faster). And later came Github. Latest contender is https://pijul.org/ , which claims easier conflict resolution, ability to work with part of repository and handling of binary files, but so far completely misses social aspect.

danhab99• 3 years ago

I wish git would stash changes when I checkout uncommitted code

CableNinja3• 3 years ago

You can make this happen with a git alias[1].

https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases

Yajirobe• 3 years ago

I thought git complains and doesn't allow you to checkout uncommitted code? Something along the lines of 'please commit or stash your changes before checking out'

recursivecaveat• 3 years ago

You can do it as long as your changes are only to files that are otherwise identical on both ends of the checkout (meaning there's 0 possibility of conflict).

CableNinja3• 3 years ago

It does, they wanted an automatic thing to happen. Imo, i would never want this by default. that complaint/warning has saved me a number of times, from breaking other things

tambourine_man• 3 years ago

anyway, where we we?

I think it was supposed to be where were we

mhb• 3 years ago

Was there some traumatic incident with upper case in the author's past?

i_don_t_know• 3 years ago

The first time I tried to use git, I shredded my repo trying to revert an edited file.

bigstrat2003• 3 years ago

Yeah I've had similar experiences. I can make my way around git just fine now, but the learning curve was not pleasant. Git is one of my two perennial examples of "why programmers should not be allowed to design UIs, because they suck at it" (the other being vi).

worldmerge• 3 years ago

Are there other free (like payment) alternatives to git?

The only other one I know of that can be used for large files is https://www.plasticscm.com/ .

poidos• 3 years ago

maybe fossil[0]? Not sure about `large files` (and in fact I went to comment to ask about anyone using it 'in production' when I saw your comment)

[0] https://www.fossil-scm.org/home/doc/trunk/www/index.wiki

sgbeal5• 3 years ago

Re. large files: fossil inherits sqlite's limit of 32-bit signed integers for blobs, so 2GB. Fossil's own developers (myself included) have never come anywhere near that limitation in everyday SCM use.

kstrauser• 3 years ago

Mercurial is still actively developed.

rebolek2• 3 years ago

And its interface makes more sense than Git.

martinvonz2• 3 years ago

There's Jujutsu/jj: https://github.com/martinvonz/jj

It can be used with regular Git repos.

kelseyfrog• 3 years ago

Yep, ran into the "don't change your name" edge case. I have the choice of rewriting history and coordinating that amongst team members, dealing with it, or switching companies and never working on the project again.

So far, I just deal with it, even though it chips away at my soul each time it comes up.

Forge36• 3 years ago

Is there a reason .mailmap doesn't work in your case?

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

If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file or mailmap.blob configuration options (see git-config[1]), it is used to map author and committer names and email addresses to canonical real names and email addresses.

fanf26• 3 years ago

Not all git commands consult .mailmap when they should, so it’s a very leaky and incomplete way to address the problem.

jonmayer6• 3 years ago

I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved.

It's now 6000 lines of bash.

(Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)

CSSer• 3 years ago

What’s the shellcheck output look like? Sounds marvelous.

jonmayer6• 3 years ago

Shellcheck clean. But I still want to port it to python.

Buttons8406• 3 years ago

Is it easier to learn the simple concepts of git and have transferable knowledge, or to learn your proprietary 6000 line bash script?

jonmayer6• 3 years ago

It's easier to support a company of users when everybody is using the vcs tool in a consistent way.

thegrim33• 3 years ago

How do you reconcile this with the fact that the vast majority of git users, both at small and large scales, do not need to do this? Now you have a massive, proprietary to your company, system for committing code that every person that joins the company has to learn and maintain.

jonmayer6• 3 years ago

That's a good question. My wrapper isn't meant to insulate the users from git, it's meant to teach git. It shows every git command it runs and gives the user an easier on-ramp.

fouc4• 3 years ago

I'll open source it as soon as I rewrite it in Python.

Realistically speaking, will that happen? Why not throw up the bash code as a separate repository from the python one anyways? As an example. Could throw it into archived mode right after or something perhaps.

jonmayer6• 3 years ago

It will happen, but if you want to see the bash, warts and all, here you go.

https://github.com/enfabrica/enkit/blob/master/scripts/gee

One of the big issues you'll find is that some off the defaults are very specific to my company. I'll fix that in the rewrite.

anonyme-honteux• 3 years ago

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

git doesn't suck. It's the best possible version control system in the context where it was produced, i.e. the Linux Kernel, i.e. an ultra large bazaar style project with hundreds of developers gifted at getting the low level details right.

It was not however designed for the kind of projects I work on, more Cathedral style, a few people who know and trust each other, where learnability, usability, and just not getting in the way are important factors.

The SQLite people have a concurrent to git called fossil. I found their description of why they started and maintain the project incredibly interesting

aeurielesn• 3 years ago

There was a podcast with the author of SQLite explaining pretty much why he doesn't use anything by anyone else.

sgbeal5• 3 years ago

There was a podcast with the author of SQLite explaining pretty much why he doesn't use anything by anyone else.

To summarize, his (Richard Hipp's) definition of freedom is "being able to take care of yourself." That includes reducing third-party software dependencies to the absolute minimum (e.g. libssl is not something he wants to reimplement... though we have (very) idly tossed the idea around ;)).

fbdab103• 3 years ago

The number of people who will insist that Git needs to be this way because of its power. If only you would bother to study the internals, you would see how beautiful it is on the inside. Why don't you just learn your craft?

Like, fine, you are just so much smarter than me. I have spent many hours going through tutorials and the documents, and I still run into problems from time to time on doing things that feel like they should be routine.

I can have a surface level understanding of most other tools without fear of breaking the world.

donatj• 3 years ago

on a similar note, it would be nice to be able to have multiple authors in a commit message. it's one of the few times in git that there's only one of a thing allowed.

I mean that's just not true.

https://docs.github.com/en/pull-requests/committing-changes-...

fanf26• 3 years ago

The point tef is making is that a commit header can only have one Author: field. If you want more than one author you have to work around git’s design limitation using ad-hoc trailer fields as described by your link.

danShumway7• 3 years ago

Comes up in every conversation I have about Emacs, Git, CSS, etc: Just because a tool is the best at what it does, that doesn't necessarily mean it's good at what it does. Those are two different metrics.

There's no danger of me dropping Git, the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. But Git definitely still has flaws; a lot of this post rings true to me.

I do think that Git gets a lot better the more that you understand how it works. Not perfect, a lot of the flaws being pointed out here are core flaws with Git's internals and have nothing to do with the UI. But it does get significantly better; some of the failure modes are much easier to avoid if you've spent time digging into how Git works, and the whole thing starts to feel a lot more elegant the more that the abstractions are stripped away. But that's also kind of a flaw in itself: Git's user interface is much more complicated than the underlying program or concepts are, which is obviously not great.

sgbeal5• 3 years ago

the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does.

The fossil developers (myself included) would be interested in hearing what those mistakes are. We're open to improvement so long as they don't break backwards compatibility (e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil).

danShumway7• 3 years ago

e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil

We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collaboration that also allows me to have documentation around repository history, and I don't think that immutable history helps with either documentation or collaboration.

Obviously some people disagree with me on that, but the really short answer is that I think the way Fossil defines version control is misguided, so it's unlikely I would ever make the switch over.

BoiledCabbage• 3 years ago

That's fundamentally the issue with git. It's underlying concept is good - probably still a tad bit more convoluted than it needs to be with the benefit of hindsight, but that's fine. It's hard to design software. But it's overall user experience - the way you interact with it is horrific. It's is so incredibly convoluted. So much inessential complexity. Half of learning to use git is learning to look past the convoluted interface and see/understand the simpler concepts behind it.

It's legitimately one of the largest divergences between simplicity of concepts and complexity of UX/interface of any serious tool I've ever worked with in my career.

Again, it's huge service and absolutely a benefit - but also the amount of collective dev hours wasted on understanding git minutiae is way too high.

danShumway7• 3 years ago

When I teach Git in mentoring situations, I start with the underlying concepts before I even touch the user interface. And that's kind of wild, it's a testament to how bad the user-facing interface is that I'm thinking about it through the lens of "understanding the internals will make the UI easier", not "understanding and working with the UI will make the internals clearer."

yowzadave• 3 years ago

If this is true, do you think it would be possible to write a new UI for git that is compatible with git repositories, but more accurately (and intuitively) exposes those underlying concepts?

martinvonz2• 3 years ago

Jujutsu/jj (https://github.com/martinvonz/jj) keeps most of Git's data model and tries to improve the UX. It can even be used with existing Git repos.

danShumway7• 3 years ago

Thanks, will take a look.

fouc4• 3 years ago

Git's user interface

When I encountered git back in 2006, I was kinda surprised at the choices of git's commands & arguments, it didn't seem nearly as nice as SVN's command-line interface. But git did win out for being usable locally & the sheer speed.

I kinda hoped the command-line interface would get revamped w/ better command names & better argument structure, but that never happened I guess.

rstuart41332• 3 years ago

Linux seemed to loath svn with a passion. I really some comment from him like "they simply don't get it". With the benefit of hindsight, he was right.

But he did throw the baby out with the bath water. They got the data structures wrong, the overall concept skew whiff (a commit is the code at a point in time; how you got there is just meta data), but the higher level interface wasn't bad. He could have done worse than to base the porcelain command names on svn.

x0x02• 3 years ago

I'm dying laughing

submodules? they're a file in the repo with a special type inside the trees, git knows when checking out that the file is special, and could run other commands. it then does not run those commands and the person using submodules begins crying.

For a while, at my company, we used a git submodule (err, I unfortunately used a git submodule... this was my fault) and it was tradition for every new engineer to have a bad deploy because git silently ignores the submodule not existing on disk. So they would deploy, the submodule would be missing, and boom.

Buttons8406• 3 years ago

Your deploy process says nothing if several (possibly thousands? a submodule can be big) files are missing and this is a complaint you have about git? It sounds like more of a complaint about the deploy process.

x0x02• 3 years ago

There certainly were defects in the deploy process, and we have since moved to a much better method. This was our docs tree, so it didn't break the code, just the, well, public documentation.

It just was annoying that you can use a submodule but git will happily ignore it not existing. It just made the whole thing super janky.

rwmj• 3 years ago

Just wait until you bisect in a tree that contains a submodule, forget the mandatory manual update step, and your day long bisection is wasted.

If you have to bisect across commits that added or removed a submodule you might as well give up now.

PurelyApplied• 3 years ago

There are so many things to dislike about git, but I feel like so much of this post is reaching for cause to be offended.

Sha1 is a hashing function. As a hashing function, it's fine. Why does your identifier need to be cryptographically secure?

I agree with the name and email issues, but laughed at the ideal that a URL is somehow more robust.

Who claims that git is a database?

I agree with the broad strokes, especially having as many conversations as I've had with frustrated people about why their repo is in an unhappy state.

rileymat2• 3 years ago

Why does your identifier need to be cryptographically secure?

There are many use cases where people are using the hash to guarantee no actor has inserted different code than they expect in a dependency, so the dependency is pinned to a hash. Not being secure, would be catastrophic for some use cases that people are currently using if widespread.

We could make a claim this is a misuse, but this is what people are doing.

fanf26• 3 years ago

Git was using SHA1 as a cryptographically secure identifier right from the very first month of its existence. https://github.com/git/git/commit/65f0d0ee4627dd0f0468ceded3...

Macha2• 3 years ago

sure enough, when you store names in the files, you have to rewrite history when someone changes email address, but in another world, you'd use a uuid and a file called .gitauthors that maps one to the other—and you wouldn't even have to put email addresses in the file, you could just put github urls or similar.

I mean, it's called .mailmap, and it's a map of commit email to cannonical email instead of uuid to canonical email, but this basically exists: https://git-scm.com/docs/gitmailmap

rebolek2• 3 years ago

I can understand not using capital letters for short informal messages, but reading whole article written in such style is hard.

That said, I agree with most points. The main problem with Git is that it's not bad, it's good enough. Mercurial and Fossil are superior, but Git is good enough, so people won't switch.

orwin• 3 years ago

Fossil seems superior (never used it professionally though), but i did use mercurial, and in practice it's really inferior imho. It isn't much simpler, as my git aliases are with me since 2014, and that make git as simple to use (for me) as mercurial in cli. If i need to work with VSCode, both plugin are as "easy" to learn anyway. Magit is just more efficient (thus easier) for idiots like me that had too much time at school, but i understand this is a bad argument.

But no reflogs and no rebase makes it harder to use branching locally, and branching in general in mercurial isn't as flexible as it is in git (ok, i get it, it is footgun, but an airsoft footgun imho).

danielovichdk• 3 years ago

Seems more like a rant where the author does not even show how he gets himself into the trouble is tries to describe.

Rebase, merge, and submodules being good examples. Show what you are trying to do and it becomes a whole lot easier to understand. Who uses rebase often anyways ?

Poorly written also imo.

argulane• 3 years ago

I use rebase every day because fix typo commits are not useful and having good commit messages helps a lot with code review

Guvante• 3 years ago

I think GitHub is half the problem with how people perceive Git.

There are friction points between how Git works and how GitHub wants to do them.

Rebase is a nice compromise between merge which makes reading history and hard and squash which loses intermediate commits (sometimes breaking rename detection). But of course you cannot include a reference to the PR anymore outside the GitHub UI or manually rewriting commits.

Similarly having the type of merge be treated as a last second choice instead of part of the reviewable flow increases "wrong button" incidents a lot.

fouc4• 3 years ago

The git authors as UUID suggestion seems good to me. Will that get implemented in git?

politelemon• 3 years ago

git for windows does "merge rebase" commits that preserve history during rebases: it creates a merge commit with the latest version, replays the existing commits atop...

Could someone show what this command looks like or link to docs? Searching for it produces a lot of rebase Vs merge results.

begoon• 3 years ago

I’m always puzzled when people say than git is hard, confusing etc. Is English hard to learn? Russian? Chinese? It depends, as always.

Yep, it’s a learning curve, and as deeper understanding comes, in more ways you start bending this great tool (git).

There is an endless ocean of toolings, helpers etc of all kinds, for all levels.

I’m not saying git is the best. There is no the best tooling in general. Fossil is great, git is great, and some other VCS. Pros and cons are everywhere.

git is a battle tested software. Who argues?

Things I just don't like about Git

Related Stories