Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

191–200 of 559 posts

Re: Is Git Irreplaceable? (2019)

#191
post #97

Earlier quoted context omitted.

Git is extremely user-unfriendly from the command line. It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.

I don't think that's true. I've been using git's CLI since I started using git a few years ago, and exactly zero of my problems with git could've been solved by a different user interface (be it GUI or a "better" designed CLI). Pretty much all of my problems have been with my lacking understanding of the abstractions that git uses to make all of the powerful things it can do possible.

> I don't think that's true.

You are in the minority. It's such a ubiquitous experience, a running joke in the industry. Saying a tool is useful and powerful, is fine and good. That sentiment has nothing to do with usability.

Re: Is Git Irreplaceable? (2019)

#192
post #97

Earlier quoted context omitted.

Git is extremely user-unfriendly from the command line. It would also be nice to have a repo that isn't language-agnostic. It's too easy to track non-semantic changes, like white space.

I don't think that's true. I've been using git's CLI since I started using git a few years ago, and exactly zero of my problems with git could've been solved by a different user interface (be it GUI or a "better" designed CLI). Pretty much all of my problems have been with my lacking understanding of the abstractions that git uses to make all of the powerful things it can do possible.

Isn't that the same thing? If you need to be taught the underlying abstraction to be able to understand the UI you've got a text book example of leaky abstraction.

After I had to unfuck a repository for the n-th time, I trialed a switch to Mercurial, we switched shortly after. I can count on one hand how many times I've had to intervene in the last few years.

Re: Is Git Irreplaceable? (2019)

#193
post #152

Earlier quoted context omitted.

Mercurial is probably that competitor. Only slightly slower than Git. Works on very large monorepos (as large as Facebook's or Google's monorepo). Very similar workflow as compared to Git, with some minor differences in terminology.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

Paper cuts can be addressed with more users reporting bugs and contributing fixes. The fundamental design issues with git that prevent scalability cannot.

As a Google employee I use hg every day, even though it's not required. (Some teams at Google do mandate its use, but these are few and far between.) I don't use branches, but I use bookmarks. I didn't notice any merges that really ought to be performed automatically but were not; in any case I use Meld to resolve merge conflicts and it's easy enough to do occasionally.

Re: Is Git Irreplaceable? (2019)

#194

One major fundamental issue with git that nobody has brought up is that its data model is close-to-incompatible with some of the current legal and moral requirements around data privacy today. For example, as far as I can tell, GDPR allows any European citizen who has ever committed to the Linux kernel to request that their name be permanently expunged from their contributions, and everyone with a git clone of the ke…

Could you cite the paragraph of the GDPR that requires this?

Re: Is Git Irreplaceable? (2019)

#195
For what it's worth, the linked page is itself running on Fossil, which has of course build in forum facilities and several other suchlike goodies - being a complete solution, packed into a single smallish executable with no significant dependencies apart from SQLite. The Fossil site runs on very moderate hardware, and gets no hiccups from hitting the HN frontpage.

I like this kind of untroubled minimalism, and so far have never encountered a reason not to run every personal project on Fossil. The real world will occasionally force me onto Git territory, but I can't really say I have ever enjoyed the experience.

Git is here to stay for any foreseeable future, of course. And while I do understand points often made about the benefit of one de facto standard to rule them all, monolithic dominance always tends to unsettle me. My SE friends in general simply use 'Git' as a given synonym for 'version control'. And it does annoy and somewhat worry me that they've never even heard of Fossil until I roll out my sermon.

Re: Is Git Irreplaceable? (2019)

#196

Earlier quoted context omitted.

> I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). You're confusing a hosting service with being forced to use a centralized repository. Take GitHub, for example. If git was centralized them you would not have forks, multiple remotes or multihosting, or could even work independently of the remote server. With Git, you can even set up a repo in a net…

Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.

Git does far more than making it easy to fork: it makes it trivial and inexpensive.

Meanwhile SVN supports forking in the sense that it supports copying directories.

Re: Is Git Irreplaceable? (2019)

#197
post #150
post #48

Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) le…

"Barney Oliver was a good man. He wrote a letter one time to the IEEE. At that time the official shelf space at Bell Labs was so much and the height of the IEEE Proceedings at that time was larger; and since you couldn't change the size of the official shelf space he wrote this letter to the IEEE Publication person saying, since so many IEEE members were at Bell Labs and since the official space was so high the journ…

What is the analogy here? The first guess that came to my mind was the monorepo versus multi-repo debate: since Git can only support repos that are so large (shelf space) without getting slow, you should split up your repos (journal size) even if semantically you would prefer a monorepo. But that would support the point I was making, whereas the obliqueness of your reply makes me think you probably meant to criticize it.

Re: Is Git Irreplaceable? (2019)

#198

Earlier quoted context omitted.

The so called problem would also vanish if the monorepo was modularized and broken up into smaller repos.

That's probably a harder task for an existing monorepo that is too big for git than writing a replacement for git that works with a repo of that size.

The problem boils down to refactoring a large monolith. I feel like Git is a scapegoat for a much larger problem.

Re: Is Git Irreplaceable? (2019)

#199
> I worry that Git might be the last mass-market DVCS within my lifetime.

The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

Re: Is Git Irreplaceable? (2019)

#200
post #158

Earlier quoted context omitted.

I disagree that Git's biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google). Git's flaws are primarily in usability/UX. But I think for its purpose, functionality is far more important than a perfect UX. I'm perfectly happy knowing I might have to Google how to do something in Git as long as…

I work for a 40-people game studio. A major limitation of git is how it deals with many "big" (~10Mb) binary files (3D models, textures, sounds, etc.). We ended up developing our own layer over git, and we're very happy ; even git-lfs can't provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.

This does not surprise me. Git's original purpose of managing versions of a tree of text files (i.e. the source code of the Linux kernel) pervasively influences it, and I wouldn't expect it to be any good for working with binary files or large files.

If somebody comes up with something that matches Git's strengths and also handles binaries and biggies much, much better then they could definitely topple Git with it. It'd take time for the word to spread, the tools to mature and the hosting to appear, but I can definitely see it happening.

I think most people know that Git isn't perfect, but it's also the case that coming up with anything better is an extremely difficult task. If it wasn't, someone would have already done it. It's not like people haven't been trying.

Post reply on HN