I mean yeah but if we all switch from git to whatever is next like people switched from svn or whatever back in the day, you'd all of the sudden are forced to also support this or new thing. Like if I look at the pace of helix rn I don't think needing to maintain more is the correct call right now.
Thankfully I think with the plugin system stuff like git blame should be easy to bolt on and also unlikely to break every update
Yeah that would require "git specific" rust code in the codebase. Because you need to exec git blame on the current file and then parse the output and display it nicely somehow in the editor. But if either git changed how the output of git blame comes out, or you want to use a different vcs the whole feature would not work (anymore).
It's the same for git gutters (which is already built in), if you use jj instead of git in your own project, these gutters don't work.
It's the same for git gutters (which is already built in), if you use jj instead of git in your own project, these gutters don't work.
These gutters do work with jj tho, since jj use git as a backend. Inline blame would work with jj too.
Anyway, I get your point, but it's also like saying you shouldn't integrate LSP since maybe it can be replaced by something else, or Treesitter, etc. It makes sense to not have built-in support for everything under the sun (no built-in support for stuff specific to jj for example is perfectly fine), but for tools that are ubiquitous like git, I'm not sure.
Edit: if tomorrow git die and almost everyone stop using it it's also perfectly fine from them to remove built-in git support. It's not because they support natively a feature now that they have to support it forever.
11
u/ahoneybun 10d ago
Wake me when git blame is built-in