201–210 of 559 posts
Earlier quoted context omitted.
But did you think that RCS, CVS, or SVN were also good enough? Or is this new?
These fell by the way side as they never had consensus of being better than SCCS. Now git has the weight of the Linux kernel behind it which pretty much EOL'd all other source control mechanisms.
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…
What bothers you in particular?
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.
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…
If that was then extended into the version control system that'd be even better. Oh yes.
But getting a new language into these things would probably be a nightmare.
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
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.
And they do occasionally put some new stuff in that helps. Like the recent version which adds new commands to split out the two completely different uses for `git checkout` (making/switching branches and reverting files).
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.
> 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. In my opinion this is a problem with programming languages rather than version control. Namely we mix presentation and representation when using text as our source code. In the case of whitespace we have an infinite number of syntactic presentations which all correspond to the same seman…
Earlier quoted context omitted.
But did you think that RCS, CVS, or SVN were also good enough? Or is this new?
These fell by the way side as they never had consensus of being better than SCCS. Now git has the weight of the Linux kernel behind it which pretty much EOL'd all other source control mechanisms.
From what I saw, it was git vs hg - which had different philosophies. Hg gave you nice, polished workflow for supported tasks. Git gave you building parts that you can make your own system from. It turned out that enough programmers wanted to build from parts.
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…
Scaling isn't even just about number of files or size of them. A problem I've hit is just in having cross-repo stuff work well. Monorepos are helpful partly because git submodules are not ideal for good workflows, and splitting stuff across multiple git repos can backfire (it doesn't help that almost all the tooling around CI and the like is repo-based instead of project based). I would love a layer over Git to handl…
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…
> 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). I constantly run into git scalability issues as an individual. I don't use any of the UI clients because they all fail hard on mostly-code git repositories. I abandoned my VisualRust port in part because the mere 100MB of mingw binaries involved for that meant it was using gi…
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> 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.
I actually prefer SVN and HG style branches where you keep the branch history as a known formal branch, then have one merge back to Trunk. It is unclear to me how far back you are saying SVN did not have branching.
One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations.
But the main workflow of creating a feature branch, developing a feature, then merging it back into the trunk/master, has, as far as I know, always been supported in Subversion.