Feature/Refacto: Conflate all VCSes under an umbrella vcs
module
#5932
Labels
✨ enhancement
A new feature implementation.
vcs
module
#5932
Feature Request
Context: original idea came from #5772 (comment)
Is your feature request related to a problem? Please describe.
A few months ago I started using
jj
a lot.jj
as a mode where its.jj/
folder is colocated with the.git/
folder. Using #5814 I then end up with bothgit
andjj
in my prompt when I only want the later.I suspect this can also happen for people in very specific setups where they use
hg
for one mirror andgit
for another but I don't know of any real world case for that. If you have one I'm interested!Describe the solution you'd like
The solution I'm thinking of is the following:
Top level VCS modules would disappear and only
$vcs
would be available instead of$git_state$git_branch
for example.Advantages
vcs
module to detect that for example both$git_state
and$git_branch
are used and so do one request to get all the information instead of two. For most repos it's not a big deal but it could help thegit_status
module be less costly on bigger ones maybe.jj
for example, where using a library is not possible, it would be very helpful to do that.hg_branch
andgit_branch
currently,starship
has to check for both. Withvcs
, once it findsgit
(with the order above), it stops, avoiding paying the cost forhg
Disadvantages
jj
case, if I wantgit
infos, I dogit
commands since it's very rare: paying the cost on every prompt seems strangevcs
uses the config from the top level modules (git_branch
instead ofvcs.modules.git_branch) instead of having its own subconfigs.
vcswould then end up with only
orderand
format.` as members.$vcs
trying to fix that, ...), especially considering it opens the option of$vcs$git_branch
in the prompt config. We could disallow having "top level free VCSes modules" in the same prompt as$vcs
but I think that would be a first instarship
and not a good experience for a user trying to build their own prompt.Describe alternatives you've considered
There is #818. The problem with that is that we don't have a
Repo
type for all VCSes nor even a Rust lib to use. We could "fudge" it by having our ownRepo
type for those missing ones but that's probably not a repo anymore but just a cache of relevant infos and would be confusing to document.This issue also mentions having
$vcs_branch
instead of different$<vcs>_branch
for each VCS: that's wrong because it implies all VCSes will have a concept of branches that map to each other but that's not the case at all:git
,hg
,pijul
,jj
andfossil
are the VCSes I'm thinking of and they don't all have the concept of branches, sometimes it's not under that name (e.g. "channels" inpijul
) and while branches are one of the most portable concept, lots of others are not:change_id
vscommit_id
injj
, topics inhg
, tags fromgit
Working on it
I'm fully willing to do the work on all of this! This is an issue is to confirm maintainers are interested and hash out issues before I spend hours working on it :)
The text was updated successfully, but these errors were encountered: