Support for other VCS

[zegervdv]

Hi,
I really like the functionality and UI of this plugin, especially for large repositories it is very useful to quickly get the history of the current file in a nice and clear overview.

Sadly most of my work is in mercurial repos and I would love to get a similar experience there.

I spent a couple of hours trying to get familiar with the code base and try to hack in mercurial support, but I think as it stands, the code is very much hardwired for git and it would require a large refactor to enable support for other VCS’es.

So my question is: would you be open to take on that burden of supporting multiple VCS’es (mercurial in particular)?
If so, I am willing to do (some of) that work with your guidance. I guess you probably have some ideas on how you would prefer to implement such a change.
At the very least I can help out with the equivalent mercurial commands to get the required data, but I’m definitely willing to help out more.

Either way, thanks for your time.

[sindrets]

@zegervdv Thank you for taking an interest in the project!

My stance on including support for other VCS' is that: I don't personally use any other VCS than git, and I'm not interested nor capable of working on such functionality myself (without spending a lot of time familiarizing myself with VCS software that I don't use). However, I'm willing to include it if it's developed and maintained by other people.

It's also fine if it doesn't have full feature parity with what we're offering for git. We can just add a disclaimer that mercurial is only partially supported (if that's the case). I don't know how well i.e. the git-log options translate to mercurial. But I'm guessing that it offers at least similar things.

Is this something you would be interested in working on?

[zegervdv]

I definitely understand you don’t want to take on extra work for something you wouldn’t use yourself, which is why I wanted to ask before diving deeper into it.
I would like to work on it and keep supporting it.

As for the feature parity, I think it should be possible to get the core functionality matched, probably with some different options or flags.
As a first goal I’d like to get DiffviewFileHistory working.

Practically I think this will probably take a couple of PRs. Currently I think the git module is a combination of an abstraction layer and git specific code and that should probably be broken up into a common base and VCS-type specific module using the same interface. Based on which kind of repo you are in the right specific module (git or hg) could then be loaded.

Does that sound reasonable? Do you have any suggestions or ideas how you prefer to tackle this?

[sindrets]

I would like to work on it and keep supporting it.

@zegervdv Brilliant, thanks!

Currently I think the git module is a combination of an abstraction layer and git specific code and that should probably be broken up into a common base and VCS-type specific module using the same interface.

Yes, I agree that this is the way to go. We could create a new lua/diffview/vcs/init.lua that would act as a bridge between different VCS adapters.

Here's a rough checklist of what needs to be done in order to get mercurial working with file history:

• Refactor the current lua/diffview/git/utils.lua into something like lua/diffview/vcs/adapters/git.lua.
• Implement some utility function that can detect what VCS repository a given path is part of. Similar to how find_git_toplevel() is used currently.
• Begin work on the mercurial adapter lua/diffview/vcs/adapters/mercurial.lua:
  • Port most of the public methods from lua/diffview/git/utils.lua.
  • I'm guessing that parsing is probably going to need some adjustments for mercurial, but hopefully you can use some of the code for git-log parsing:

    diffview.nvim/lua/diffview/git/utils.lua

    Line 857 in a1fbcaa

    local function parse_fh_data(state)

• The file history option panel is probably going to need the capability to show different options depending on what VCS is currently in use.

Let me know if you have any questions regarding the implementation, or the code base.

[zegervdv]

Alright, I'll start with the first point, that will probably be the bulk of the work.

I'll start a PR for that soon, that is probably easier to discuss the details.

[zegervdv]

with the merge of #255 I think this can be closed