Live data from Hacker News

Things I just don't like about Git

cohost.org

41–50 of 118 posts

Re: Things I just don't like about Git

#41
> 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

Re: Things I just don't like about Git

#42
post #6

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.

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 int…

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

Re: Things I just don't like about Git

#43

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.

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.

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

Re: Things I just don't like about Git

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

Re: Things I just don't like about Git

#45

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…

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.

Re: Things I just don't like about Git

#46

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.

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

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

Re: Things I just don't like about Git

#47

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.

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

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

Re: Things I just don't like about Git

#48
post #6

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.

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 int…

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.

Re: Things I just don't like about Git

#49
post #39

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…

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

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

Re: Things I just don't like about Git

#50
post #6

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.

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 int…

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

Post reply on HN