Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

141–150 of 559 posts

Re: Is Git Irreplaceable? (2019)

#141
Does Fossil do sub-modules correctly? Specifically does it let you compose a project of several repositories and do configuration management on that repository? That is something git kinda sorta does but it gets out of control easily.

Re: Is Git Irreplaceable? (2019)

#142
post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell

Yes -- that's what it means to be a flaw with the entire current generation of version control systems.

"Need a centralized server" wasn't specific to one (pre-DVCS) system, either.

Re: Is Git Irreplaceable? (2019)

#143
post #29

I am happy to use whatever everyone else starts using, provided it works at least as well. But I also do not have many problems that git won't solve, so I don't feel a burning need to switch. I think git is good enough that source control is no longer a very interesting problem.

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

> But did you think that RCS, CVS, or SVN were also good enough?

SVN required a centralized server and didn't even supported branching, so no.

Re: Is Git Irreplaceable? (2019)

#144
post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

I’ve read a couple descriptions of the internals of git that don’t disagree with the design of SVN, so I’m not unsure why you can’t theoretically check out a single subtree. Either the documentation is too hand wavy or some implementation details have blocked that possibility.

Re: Is Git Irreplaceable? (2019)

#145
post #84

Earlier quoted context omitted.

If I were to pie in the sky dream up a replacement for git, I'd have it store the AST of the parsed code instead of a text file. It would solve a lot of problems with refactoring crapping all over the history. Like I said, pie in the sky. Probably never gonna happen. Personally I don't see git's problems with large binary files and tens of millions of commits as being major issues. Those two alone are way less valuab…

What you want has nothing to do with git (which is a storage model). You can use arbitrary diff and merge resolution algorithms with git's plumbing, which would give you the AST-aware functionality that you want.

Except you have to run them every time.

Imagine instead of that were available as a sort of materialized view.

Re: Is Git Irreplaceable? (2019)

#146
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…

What are you smoking? GitHub and gitlab together basically encompass almost ALL of humanities efforts with regards to software development. Doesn't scale??? You are seriously delusional.

Re: Is Git Irreplaceable? (2019)

#147
post #89

Earlier quoted context omitted.

I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell

>I don't see any obvious flaws with Git. Large files and long histories hinder its total dominance in the game and art industries. Because of git's shortcomings polyrepo is a near necessity not simply a stylistic choice. LFS is a bolt on solution that could/should have better support.

Git stores the diffs in chronological order doesn’t it? I recall reading about someone doing a commercial implementation where the commits are stored in reverse chronological order. I’d been thinking that was github but I’ve never been able to find the article again.

Re: Is Git Irreplaceable? (2019)

#148

Earlier quoted context omitted.

Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge fro…

I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "hos…

> 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 network file system somewhere, or even a USB thumbrive.

Re: Is Git Irreplaceable? (2019)

#149

Earlier quoted context omitted.

> I don't see any obvious flaws with Git. Merge conflicts.

Merge conflicts are not so scary, and are an elegant way to handle distributed changes with simultaneous edits to a single file. If the conflict is huge, rebasing can help you by "playing" the commits from one branch one at a time so the conflicts are smaller / easier to fix. At a previous job, a team was forced to use checkout-style VCS due to their manager's unfounded fear of merge conflicts; I couldn't go in that…

I’ve spent too much time helping others fix bad merges, and I still catch myself making mistakes. There’s a lot of work that could be done for clarity and error avoidance.

Re: Is Git Irreplaceable? (2019)

#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 journal size should be changed."

- http://www.paulgraham.com/hamming.html

Post reply on HN