Any thoughts on git competitors/extensions e.g. google jujutsu/meta sapling/git-branchless?

[NotBrianZach]

https://github.com/martinvonz/jj/blob/main/docs/related-work.md

might not be suitable as a feature request but maybe a fork? Curious to hear opinions on the space.

[mohkale]

For what it's worth I'm interested in sapling and would love to create a magit like package for it. I think it would be nice if we could abstract out the generic parts of magit and make it so just magit works even for non git style projects. Perhaps with a class that each vc source can define for the common stuff (status, top level commands, console buffer, etc.) and then magit invoke can alter which backend it uses based on this. I'm not sure how difficult this would be, hopefully tarsius can share his insight.

[tarsius]

I think it would be nice if we could abstract out the generic parts of magit and make it so just magit works even for non git style projects.

Well, some things have already been factored out of Magit: transient, with-editor, and (despite the name and being maintained in the same repository) magit-section.

But it sounds you are hoping for more than that:

Perhaps with a class that each vc source can define for the common stuff (status, top level commands, console buffer, etc.) and then magit invoke can alter which backend it uses based on this.

That's basically what VC (vc.el et al.) does. You might want to extend that instead of Magit. I haven't used it in a long time, but believe some magit-like functionality, like a status buffer, have appeared over the last few years.

Using the same approach for Magit is not feasible. Maybe that could technically be done, but for me that would mean investigating a lot of time into things that don't actually improve Magit for Git users.

That being said, there are certainly parts that could be abstracted further, but it will never become possible to add support for another vc by just implementing a hundred generic functions for that vc.

Magit won't support other vc. You can of course get a quick start when creating something like Magit for another vc, by copy-pasting a lot of existing code, and learning from successes and failures of Magit.

[mohkale]

That's basically what VC (vc.el et al.) does. You might want to extend that instead of Magit.

Yes. I'm actually working on vc and project.el integration for sapling atm :-).

I have looked into vc in the past but to be frank magit is too cool to leave 😎. I'm so accustomed to the ease and convenience of a transient like interface for vc I don't think I can move past it. Thanks for that XD. I don't particularly mind starting from the ground up to create a magit like interface. Perhaps to begin with just a series of transients for interacting with sapling. I've begun using it day-to-day and so far it's familliar but clearly different to git. I'd appreciate any advice you could share in this venture and of course I'd love to be able to repurpose any code from magit (as you mentioned transient, with-editor and also wow didn't know magit-sections was externalised) :-). Thanks a lot.

[tarsius]

I'd appreciate any advice you could share in this venture

Don't highlight the current section and don't bother doing something fancy with the region. Getting that stuff right is a lot of work, and once you have added it, users won't let you remove it again.

[tarsius]

Some of these are certainly interesting, but I don't have experience with any of them.

I find something like Pijul and Fossil more interesting than things like git-branchless, because the do something very different at a fundamental level.

Looking at git-branchless might be more productive though. Like Magit such projects provide new abstractions and workflows on top of Git. There's certainly features to be find there that could be ported to Magit. "Ported" is the operative word here; I don't think "wrapping" such things would be the best approach.

Another reply: That stuff is interesting, I recommend you experiment with it, unfortunately I myself am busy maintaining Magit instead, which I sometimes regret.