5 ms·

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

by aspyct 6y ago

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.

usr1106 6y ago
The plumbing is great. The porcelain would deserve a more consistent and easier to use implementation.
- hprotagonist 6y ago
  magit is grand. but editor specific.
  - kubanczyk 6y ago
    I often just magit on a separate terminal and edit with some other IDE/editor. 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.
  - dotancohen 6y ago
    That's like saying that the Git CLI is specific to CLI users. It is, but anybody can use the CLI or open Emacs no matter what they use to edit the code. I personally started using Emacs for Org-mode, but I code in the Jetbrains IDEs. Now the Jetbrains IDEs have a absolutely terrific Git integration, but if they didn't I could still open Emacs and use Magit.
- masklinn 6y ago
  > The porcelain would deserve a more consistent and easier to use implementation. 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.
Freak_NL 6y ago
Git just works most of the time, and any issues that arise tend to have to do with the complexity of the codebase rather than git (e.g., rebasing a large feature-branch over dozens of commits). 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.
jayflux 6y ago
I agree, Git will be replaced when there’s a general limitation affecting many developers and something comes along that solves that. It won’t be replaced for the sheer sake of it or because we’re “bored” of it. It’s also still actively developed so it’s not like some “stale” software we use because of inertia.
bachmeier 6y ago
> Git still works great. 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.
- compsciphd 6y ago
  I dont understand this issue. I'd argue that github PR model has simplified "submitting a patch" to a tremendous degree.
  - xiphias2 6y ago
    Github and git are very different. Github is easyer to use, but doesn't cover all of git's use cases. So actually I'm all for reworking the base commands to support a workflow more similar to GitHub's, but still distributed.
  - u801e 6y ago
    Before Github, submitting a patch required reading some documentation in the project about how to submit patches, set up one's git config to properly generate the patches and email them. Then came the part of actually making the changes, generating the patches and running a git command to submit them. 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.
    - gnufx 6y ago
      It didn't even require that. You fixed something from the immediately-buildable tarball that you'd rebuilt and tested, or even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup. You didn't have pull 100Mb of git stuff, figure out how to rebuild the build framework, find you hadn't got the submodules, prat about with a pull request, and then whatever demands it makes of you, etc. 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.
tomcooks 6y ago
It's the usual "controversial" Twitter post to boost one's account, I suggest not looking too much it and moving on
_ph_ 6y ago
For me the question is less whether Git stopped working, but whether there is any progress being made beyond Git. As Git is around for 15 years now, it is a justified question, if there are any exciting new developments beyond Git.
- eesmith 6y ago
  I think Fossil adds things beyond Git, because it also supports "bug tracking, wiki, forum, and technotes." https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki 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.
asiachick 6y ago
If you come from games you'll see where git fails miserably. Modern AAA games have terabytes of assets. p4 has handled this. git, has not. p4 also manages the fact that unlike source code you often can't merge certain assets so you need networked access controls (as in A can't edit this now because B is edit it). 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.
- thiht 6y ago
  Does it have to be a goal for Git? Most of the development is not game development
  - TillE 6y ago
    But there's no good fundamental reason why it has to be that way. 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.
- lupire 6y ago
  What about git-annex for the large asset files?
smitty1e 6y ago
There seems a focus on new=improved in human thinking. Often this is true, but fetishing change for its own sake becomes inefficient.

by aspyct 6y ago

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.

usr1106 6y ago

The plumbing is great. The porcelain would deserve a more consistent and easier to use implementation.

hprotagonist 6y ago
magit is grand. but editor specific.
- kubanczyk 6y ago
  I often just magit on a separate terminal and edit with some other IDE/editor. 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.
- dotancohen 6y ago
  That's like saying that the Git CLI is specific to CLI users. It is, but anybody can use the CLI or open Emacs no matter what they use to edit the code. I personally started using Emacs for Org-mode, but I code in the Jetbrains IDEs. Now the Jetbrains IDEs have a absolutely terrific Git integration, but if they didn't I could still open Emacs and use Magit.
masklinn 6y ago
> The porcelain would deserve a more consistent and easier to use implementation. 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.

Freak_NL 6y ago

Git just works most of the time, and any issues that arise tend to have to do with the complexity of the codebase rather than git (e.g., rebasing a large feature-branch over dozens of commits). 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.

jayflux 6y ago

I agree, Git will be replaced when there’s a general limitation affecting many developers and something comes along that solves that. It won’t be replaced for the sheer sake of it or because we’re “bored” of it. It’s also still actively developed so it’s not like some “stale” software we use because of inertia.

bachmeier 6y ago

> Git still works great. 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.

compsciphd 6y ago
I dont understand this issue. I'd argue that github PR model has simplified "submitting a patch" to a tremendous degree.
- xiphias2 6y ago
  Github and git are very different. Github is easyer to use, but doesn't cover all of git's use cases. So actually I'm all for reworking the base commands to support a workflow more similar to GitHub's, but still distributed.
- u801e 6y ago
  Before Github, submitting a patch required reading some documentation in the project about how to submit patches, set up one's git config to properly generate the patches and email them. Then came the part of actually making the changes, generating the patches and running a git command to submit them. 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.
  - gnufx 6y ago
    It didn't even require that. You fixed something from the immediately-buildable tarball that you'd rebuilt and tested, or even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup. You didn't have pull 100Mb of git stuff, figure out how to rebuild the build framework, find you hadn't got the submodules, prat about with a pull request, and then whatever demands it makes of you, etc. 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.

tomcooks 6y ago

It's the usual "controversial" Twitter post to boost one's account, I suggest not looking too much it and moving on

_ph_ 6y ago

For me the question is less whether Git stopped working, but whether there is any progress being made beyond Git. As Git is around for 15 years now, it is a justified question, if there are any exciting new developments beyond Git.

eesmith 6y ago
I think Fossil adds things beyond Git, because it also supports "bug tracking, wiki, forum, and technotes." https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki 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.

asiachick 6y ago

If you come from games you'll see where git fails miserably. Modern AAA games have terabytes of assets. p4 has handled this. git, has not. p4 also manages the fact that unlike source code you often can't merge certain assets so you need networked access controls (as in A can't edit this now because B is edit it). 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.

thiht 6y ago
Does it have to be a goal for Git? Most of the development is not game development
- TillE 6y ago
  But there's no good fundamental reason why it has to be that way. 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.
lupire 6y ago
What about git-annex for the large asset files?

smitty1e 6y ago

There seems a focus on new=improved in human thinking. Often this is true, but fetishing change for its own sake becomes inefficient.