Re: source code management refactor

On 2022-01-04 01:04, Javier Guerra Giraldez wrote:
> Hi,
> 
> I've recently pushed a small patch to add minimal Fossil support to
> Kate's Project plugin.  It felt so good to contribute to my favourite
> KDE application after many (many!) years of using it!
> 
> The next step, of course, is to get more Fossil functionality; ideally
> getting it to parity with the current Git support.
> 
> Looking at the code, I found several places like "if git, do this
> very-git thing", which of course, doesn't scale to multiple SCM
> backends.  I'm not a fan of gratuitous inheritance, but it seems the
> best way forward.  As a nice bonus, it should make it easier to add
> similar features to Mercurial, and maybe Subversion.
> 
> Now, I haven't done any real C++ since Qt3 days, so I'd like to ask
> for some comments before going too far into a bad design.
> 
> I've just pushed a new branch:
> https://invent.kde.org/javier/kate/-/tree/work/javier/fossil_branches
> It adds a `scm/` directory with a base class and a class for each SCM
> supported.  So far the features:
> 
> - SCM detection (all SCMs)
> - get managed files (all SCMs)
> - get SCM icon (for Git and Fossil)
> - get current branch name (Git and Fossil)
> - list of branches (Git and Fossil)
> - checkout branch (Git and Fossil)
> - new branch (Git and Fossil)
> 
> have been moved to use these new classes.
> 
> Is this list the appropriate place to discuss design?  or would it be
> better to open a PR and do it there (even if the code is still very
> much in process)

Hi,

first, cool that you want to help out ;=)

Now, for the concrete feature:

We started to implement Git without any abstraction as this seemed for 
us to be the 90% user
base target for some SCM people will use and therefore some abstraction 
seemed to be not that
needed on first glance.

If one can handle more SCMs with a very lightweight abstraction that 
doesn't hinder further
feature development and might increase maintainability, one could think 
about such a thing.

Given @waqar did most of the current Git work, I think he needs to be 
the one deciding if
we want that.

We discussed so far such things more on GitLab, given you already worked 
on it in a branch,
one could even just open a merge request and discuss it there, then one 
can even see
what e.g. ATM such an abstraction would imply.

Greetings
Christoph

> 
> thanks!

-- 
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org