source code management refactor
Christoph Cullmann (cullmann.io)
christoph at cullmann.io
Tue Jan 4 09:41:36 GMT 2022
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
More information about the KWrite-Devel
mailing list