What path to take?

[Perry Wagle]

Hi —

I’ve been using gitit for years now, and have come to the point where I want to make major revisions in how it interacts with the browser.

Gitit seems fairly complete, but gitit2 was started to redo it in a cleaner way, but seems to be missing a LOT of stuff. The latter now seems pretty dead, and the former on its way to the grave. So, since my life depends on my wiki, times-a-wasting in my finally doing something about keeping this thing going, and improving it for my (and maybe other people’s) purposes.

What do you all suggest for an approach? Do I start with gitit or gitit2? Both? (Port gitit to gitit2?).

Can you be more specific about what gitit did wrong? Why is gitit2 languishing?

This is just a preliminary survey to help me think this out, and give more details later.

Thanks!

— Perry

[John MacFarlane]

The main reason both are languishing is that I have limited
time to work on software, and since I don't actually use
gitit any more for my own purposes, it's lower priority than
pandoc.

I suspect that if you want to make a lot of changes, it
might be easier to work with gitit2, which is generally
much cleaner (shorter, clearer and more concise code paths),
and should be more maintainable going forward...but of
course this is not complete so you'd have to complete it
first! It is also less up-to-date; at least gitit has had
some minimal changes to keep up with new pandoc versions.
There's a list on the README of what isn't done. But in
addition to those things, revisions would be needed to get
gitit2 building with recent versions of pandoc and other
software.

So I don't think it's obvious which route to take.
One important difference is that gitit uses the
string templates, allowing easy run-time customization,
while gitit2 uses compile-time templates, which are
less flexible.


+++ Perry Wagle [Aug 24 17 22:50 ]:

>--
>You received this message because you are subscribed to the Google Groups "gitit-discuss" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to gitit-discus...@googlegroups.com.
>To post to this group, send email to gitit-...@googlegroups.com.
>Visit this group at https://groups.google.com/group/gitit-discuss.
>For more options, visit https://groups.google.com/d/optout.

[William Gallafent]

At the risk of taking this thread somewhat off-topic (sorry) but in the
broader context of answering the “what path” question:

On 2017-08-25 15:27, John MacFarlane wrote:
> The main reason both are languishing is that I have limited
> time to work on software, and since I don't actually use
> gitit any more for my own purposes, it's lower priority than
> pandoc.

Having used and enjoyed gitit on previous projects, I'm currently
setting up some infrastructure for a new one … and am wondering which
wiki / free-form linked document management system to use for this new
set-up. My original plan was to use gitit again this time round.

Coupled with a certain amount of fiddle (not yet solved) getting a
working gitit up and running on Devuan Linux 2.0 / aarch64, though, the
above quote makes me think that it might be wise to look away from gitit
to some other solution.

What do you (or anyone else on the mailing list, for that matter!) use,
these days, in lieu of gitit, as the document and notes management tool
in your workflows?

Would be very interested to hear what people find works well, and indeed
what to avoid!

My requirements are essentially not great, and remain more-or-less as
they were when we switched from TWiki (via foswiki) to gitit on those
old projects: sensible wiki syntax (clearly markdown is fine, other
basic / standard wiki formatting markup also fine); ability to render
maths into MathML for the browser from some sane markup (e.g. LaTeX)
(either natively or using a plug-in); and ability to edit off-line and
resolve divergences and conflicts using standard tools (for example, and
ideally really, as with gitit, using git to maintain a local copy of the
document repository). Free software and the ability to run the server on
Linux-arm64 are also quite high on the priority list. Ideally, the
ability fairly straightforwardly to identify and authorise users using
information from their X.509 client certificates as presented to the
server (in my case I've previously done this via a reverse proxy in
apache, which places appropriate fields from the certificates into the
environment for gitit to use), would also be present.

Reading that back makes me think I should battle on with attempting to
get gitit up and running on my devuan 2.0 arm64 system, … but it is not
what I should really be spending my time on! Unfortunately, I don't
speak anything other than extremely basic Haskell, and am equally
unfamiliar with the tools (stack, cabal, …). That means that taking on
any meaningful level of maintenance or improvement work with gitit
myself is not a viable option at the moment (particularly given my wish
to avoid the need for substantial tooling work diverting me from the
grist of a project into playing with the tools supporting it, leading to
a loss of project momentum!).

All thoughts and ideas most welcome!

--
Bill Gallafent

[William Gallafent]

[related to my other post in this thread, and more directly related to
possible future gitit development!]

On 2017-08-25 06:50, Perry Wagle wrote:
> I’ve been using gitit for years now, and have come to the point where I want to make major revisions in how it interacts with the browser.

Sounds like a plan! Multiple simultaneous users editing the same page in
situ, à la google docs, you know it makes sense, everybody likes a
challenge ;) … more seriously, or at least more on a short-medium-term
basis, though, I would certainly be interested to hear what sorts of
thing you have in mind :)

> Gitit seems fairly complete, but gitit2 was started to redo it in a cleaner way, but seems to be missing a LOT of stuff. The latter now seems pretty dead, and the former on its way to the grave. So, since my life depends on my wiki, times-a-wasting in my finally doing something about keeping this thing going, and improving it for my (and maybe other people’s) purposes.

I'd certainly be one of the people whose purposes you would also be
improving it for, as, no doubt, would be many other of the denizens of
this group :)

As such, I'd also certainly be happy to assist by running experimental
versions from an actively developed fork, in order to provide feedback,
bug details, etc., should you decide to start developing one and be
minded to share code in development! Now is a good time for me, too,
since I'm just at the point of starting at least one new project (as per
my other post in this thread!) and so am in the position to be able to
have experimental installations and “playpen” repositiories which can be
served by development versions of gitit.

I look forward to hearing your plans, and good luck! :)

--
Bill Gallafent

[Perry Wagle]

Just now saw this, sorry. I will keep you in mind as I spiral into actually working on it.

— Perry