Git still works great.
Why would it need to be replaced, just because it's 15 years old? I can think of a zillion things that are over 15 years and still very much working.
Why would it need to be replaced, just because it's 15 years old? I can think of a zillion things that are over 15 years and still very much working.
Note I love git, but I don't know any big game studios using it. Some indies get by because their games are smaller but even then it can be a pain.
The general point is: Git mostly works fine for what it is, but version control can 1) be easier to use, and 2) serve more purposes than Git currently does.
Imagine a perfect, seamless version control system that does everything you want with minimal effort. Git isn't that, not even if you've put in the time necessary to become an expert.
It’s also still actively developed so it’s not like some “stale” software we use because of inertia.
Of course, for people that know how to use it. I'd argue that the heavy use of Github combined with the adoption of advanced Git workflows is currently the biggest threat to open source. There's no such thing as "submitting a patch" these days. You're expected to be a master of a project's Github workflow to contribute. Most of us (myself included, with a few exceptions) just don't bother.
With Github, one has to fork the project, run some commands to clone the repo from the fork, make the changes, push them, and then go back to the web interface to create the pull request.
I was fine with that as a maintainer too, on three very active major projects at one time (using a 48Mb Pentium 1). A maintainer's job is partly to make it easy for contributors, not for the maintainer, but tending the contributors will help in the end.
That entirely depends on whether the necessary libraries and headers are installed on the system you're using.
> even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup
Unless someone uses emacs and gnus or something similar, email clients could end up mangling the diff unless it was sent as an attachment (which would make reviewing the code and posting an inline response more difficult).
Having to set up one's git config or having to fork a repo seem to be accidental complexity is both cases.
The next time they open a PR using that branch, it will have commits that will clutter the branch.
Moreover, I suggest you fork the project and apply your own modifications instead of worrying about a GitHub project administrator to accept your changes
You don't need to learn emacs beyond C-X 0 and C-X C-B really.
Productivity is higher than with manual git commands.
Now the Jetbrains IDEs have a absolutely terrific Git integration, but if they didn't I could still open Emacs and use Magit.
Many have taken a crack at it over the years, from very early on.
Issue's no porcelain will even replace the built-in one (and what improvements are added to the standard are generally flawed to hell, just look at how messy the brand new `git switch` already is, the git core team simply has no taste when it comes to CLI), and as the creator of a new high-level CLI by the time you'll have good enough feature coverage for it to be useful you'll know the plumbing so well the porcelain will make perfect sense. So you'll abandon the project as offering little value for the maintenance cost. And a few years later somebody else will come in and create their own, and repeat the cycle.
I think it's odd that so many people use a DVCS as part of a development system so dependent on a centralized server for everything else.
Often this is true, but fetishing change for its own sake becomes inefficient.
Besides, auxiliary tools aside (I use git shell and a bunch of aliases), the git executable too is still improving. It will be a long time before anything that might replace it reaches both the maturity and the tipping point of having enough extra features to make it worthwhile to consider switching.