Zettlr: [FEATURE] Integrate basic git functionality into Zettlr

[Mebus]

Description

To version my Zettlr notes and sync them accross multiple devices I use the very popular git version control system, https://git-scm.com/. Currently I've got to open a seperate programm or a shell to commit my changes and push them to a remote. It would be quite nice, when a basic git functionality was integrated into Zettlr.

Proposed changes

Integrate basic git functionality into Zettlr.

[boring-cyborg[bot]]

Thanks so much for opening up your first issue here on the repository! 🎉 We would like to warmly welcome you to the community behind the app! ☺️ We'll check in soon and have a look at your issue. In the meantime, you can check your issue and make sure it aligns with our contribution guidelines! Here's the comprehensive list:

Enhancements

An enhancement takes a feature and improves or alters its behaviour. Please make sure to argue how your proposition will aid non-technical text workers, and why it can't be emulated easily with other features or apps!

Feature requests

Feature requests introduce whole new features into the app. This requires a lot of work, so these might be turned down if the implementation costs supersede the benefits we expect to see from implementing it. Please do not be disappointed if that happens. It likely has nothing to do with your great request but simply with us and our missing resources!
You can of course always ask someone to implement this feature, because a PR with a working new feature has much higher chances of being merged! :)

Bug reports

Please note that one of the main reasons for why bug reports cannot be addressed is that there's not enough information for us to find and fix the bug you describe, so make sure you try to pinpoint the bug as close as possible.
The ideal bug report for us has two qualities:

1. The bug is always reproducible, at least within a certain context. 2. We know exactly what specifically goes wrong, and there is consensus on
   what should happen instead.

Please note that if you encounter behaviour that does not align with your expectations of what would happen, this might as well be simply intended behaviour and we need to simply _clarify_ why the behaviour is the way it is. This is not to be considered a bug and such issues may be closed! Suggest an enhancement instead!
But now, have a great day and thank you again!

[nathanlesage]

Already on the back of my head, but the implementation is not yet fully thought through …

[ianhi]

I don't know what implementation in the back of your head is so forgive me if I'm just repeating it here.

I think the obvious first way to add git functionality to zettlr is follow what other editors do and add a sidebar or menu that gives access to basic git command (add, commit, discard changes, push etc...). That would certainly be useful, though it may pay to be cautious about scope as I think this could be a surprisingly large burden to implement well. At least that is my experience from helping with jupyterlab-git, though maybe you could reuse large portions of the vscode git extension (src code) as that is also electron based?

As an alternative/addition to exposing git commands I'd like to suggest some sort of automatic git commit functionality built into zettlr. I've been using gitwatch in concert with zettlr which has been awesome and allows me to use zettlr as a proper electronic lab notebook. There would be two gains from adding a gitwatch style functionality directly into zettlr:

1. Easier for users (no searching for and installing wild bash scripts)
2. Could track unsaved revisions at regular intervals (perhaps to a separate branch)
   
   
   
   • gitwatch waits for file saved events so if you don't actively save the file then there is no google docs esque revision history
   
   

[shockme]

I think git functionality should be added as a plugin, rather than directly into Zettlr. Otherwise, what about people who use Mercurial, or Subversion, or Bazaar instead of Git?

[Mebus]

I think git functionality should be added as a plugin, rather than directly into Zettlr. Otherwise, what about people who use Mercurial, or Subversion, or Bazaar instead of Git?

There are no people using SVN, Mercurial and Bazaar... :grinning:

[canpolat]

I agree that there may be few people using a version control system other than Git, but I second the idea about plugins... I think some of the functionality in Zettlr is better suited to a plugin (for example, the Pomodoro timer). Basic Git functionality could be a good candidate for this. Those who don't want to use it will not have it crowding the UI.

[shockme]

I think git functionality should be added as a plugin, rather than directly into Zettlr. Otherwise, what about people who use Mercurial, or Subversion, or Bazaar instead of Git?

There are no people using SVN, Mercurial and Bazaar... grinning

That's quite a bold statement! Would you care to provide some evidence? :stuck_out_tongue_closed_eyes:

[nathanlesage]

(for example, the Pomodoro timer)

The Pomodoro timer is so trivial I don't see any reason why we should make it as a plugin.

Furthermore, let me be real quick in stopping any hopes for a plugin API in the near to mid-term future. A plugin API is among the most difficult things to do and I do not want to add any new instability causes or something else until the bigger user base together with some new things have settled (new workflows, some additional refactorings, everybody getting used to the increased exposure etc.). APIs are like crypto: Either do it right or don't do it at all ;)

To @ianhi: The latter option it would be. Please, y'all, do not forget that this app still is primarily aimed at non-technical users, so please do not expect Zettlr to become a second VSCode.

[shockme]

A plugin API is among the most difficult things to do and I do not want to add any new instability causes

You make an interesting remark which I didn't think about before. How would a plugin API cause instability?

[nathanlesage]

How would a plugin API cause instability?

Puh, there are a lot of possible things. First if could give malicious actors access to the whole app, then it might break something (because you need an interface between plugins and the application), furthermore who decides what should be exposed and what now? Then, could there be a permissions system? Etc. etc.

There's an awful lot of planning involved in a plugin API, and I know from JabRef that the costs maintaining their plugin API was so high they decided to just incorporate the most useful plugins and ditch it in the end, which totally makes sense.

EDIT: So instability in general here refers to "unexpected stuff"

[shockme]

You've answered questions I didn't ask :) I was especially interested in how an API could cause instability because that statement contradicts my own thinking on the subject and I thought I hadn't considered some aspects. From my perspective a plugin API is just a set of interfaces (or equivalent). It might be hard or it might be easy to create such an API, I guess it depends on many things, but I wasn't talking about that.

My view on the subject is that a plugin API allows many more people to add functionality via plugins who might not otherwise contribute. In my case I will not contribute code to Zettlr because of the presence of Contributor Covenant, but I would happily contribute plugins and/or contribute to the design of the plugin API.

I appreciate the work you are doing on Zettlr and I understand that you don't feel "ready" for a plugin API, so I won't push for it even though I think having a plugin ecosystem would be the better choice.

[nathanlesage]

I will not contribute code to Zettlr because of the presence of Contributor Covenant

What do you mean? What hinders you exactly?

From my perspective a plugin API is just a set of interfaces (or equivalent).

Albeit I have never programmed a plugin API, I have a strong feeling you're grossly underestimating the amount of work necessary to create something like that o.O

[canpolat]

let me be real quick in stopping any hopes for a plugin API

[shockme]

What do you mean? What hinders you exactly?

I don't have a strong opinion on Codes of Conduct in general, I just disagree very strongly with the Contributor Covenant.
A few years ago I have followed the discussion around the adoption of Contributor Covenant in the Ruby Community and I have formed the opinion that the Contributor Covenant is a political tool and has been used as such. For an example of this behavior by the author of Contributor Covenant, Coraline Ada Ehmke see https://github.com/opal/opal/issues/941. The Ruby Community has rejected the Contributor Covenant.

As you will notice in that issue, Coraline Ada Ehmke is trying to get a core contributor of Opal removed from the project for an opinion that he expressed on Twitter (not on Github, not in any technical forum, but on Twitter).

I don't know about you, but I like writing code because it's challenging and fun and I have no desire to deal with the sort of "political" stuff as you've seen on the Opal issue I linked. The presence of Contributor Covenant enables that behavior.

[nathanlesage]

@canpolat 🥺 I'm so sorry!

---

the Contributor Covenant is a political tool and has been used as such.

Yes, and rightfully so. If you closely read the linked thread, you can see that this "meh" person is basically Nick Land on crack, and from my view their reactions are disgusting. Technology is never neutral, and morality always plays an important role.

If you think the Contributor Covenant is bad because it enables us to throw out people who act disrespectful towards anyone, then I am saddened, but at the same time relieved that you do not wish to contribute to this project. I utterly despise libertarian views as uttered by some of the contributors within the linked threat such as " everyone is free to say whatever they please", because, no, here nobody is free to say "whatever they please", but to say "whatever they please with regard to certain standards".

One can say whatever one likes with regard to the topic over at Opal, but I think that the reactions toward OP there were not at all okay, and a prime example of some of the things that are utterly wrong with society.

I just re-read our code of conduct, and I did not find anything bad except an outdated email address. If whatever is written in the code of conduct goes against your world views, let me reassure you: You are free to go help other Open Source projects and not to contribute anything to Zettlr.

_Nota bene: Plugins would obviously also fall under said code of conduct, because I do not want anyone who acts against this having to do anything with Zettlr._

[canpolat]

I'm so sorry!

There is nothing to be sorry about :) I was just kidding. I understand that creating a plugin API would require effort that may be put on other parts of the project otherwise.

[ianhi]

Technology is never neutral, and morality always plays an important role

:+1:

To @ianhi: The latter option it would be.

Fantastic, that's what I was hoping for! Unfortunately I don't think I will have the bandwidth to create such a thing from scratch but I'm happy to help/test in whatever ways would be helpful. As a start towards that end I have two suggestions both derived from things I like about gitwatch:

1. Automatic commit message should be customizable. Perhaps with a string the user write that has a formatting signal for:
   
   
   
   • filename
   
   
   • various styling of the date/time
   
   
2. The option to automatically push to a remote repo is also very nice.

for example the gitwatch command I use is: gitwatch -m "(%d) | autocommit by gitwatch" -r origin . where %d is replaced with the date and it auto pushes to the origin remote.

Also, on further reflection I think what I was considering with a separate branch for autosaves is not super feasible because there would be all sorts of issues with branches getting out of sync.

(Though I wouldn't be surprised if, as before, you've already considered options like this)

[nathanlesage]

Yeah, something like this! These are all good ideas, and I hope we'll at some point be able to implement this!

[yhancik]

QOwnNotes does have a Git integration where it commits at regular intervals, if you need inspiration ;)

[innervators]

let me suggest a simple routine to effortlessly maintain your Zettlr files with Git/Github:

• before you start a new Zettlr writing project, instantiate a new local directory through Git/GitHub
• start Zettlr and register the new directory that was just created
• every .md file will be automatically processed and versioned .. commits etc. just ALT-TAB to Git/Github

too complicated?

[jotak]

too complicated?

I think the big question is: how do you manage conflicts? Embed a diff/merge editor? Ask user to fix it themselves, at the expanse of damaging the user experience?
I voted for this feature, but I understand it's not so simple.

Perhaps, as a cheaper alternative, there could be something like "configurable custom actions" that lets you call any script / command (git or whatever), triggered upon some events (manual exec, file is saved, scheduled job ...) ? It's more config left to the user, but I think less work/maintenance on zettlr side. And also wider than just git.

[yhancik]

I think there would be two ways of using it :

• automatic commits, mostly locally, to keep track of changes/history
• using git to synchronise between multiple machines/users

In the first case, I don't see how we could create a conflict, so that should remain simple for any user.

In the latter, it's already a more advanced use, and thus I guess we can expect users to solve it themselves. It would definitely be good to warn users about what they're getting into, though ("By enabling Push to Remote you're expected to understand basic git workflow so you can solve conflicts yourself" or something).

[jotak]

@yhancik yeah, personally I'd be fine with that, but it wouldn't be user friendly for people not familiar with git.
Personally I upvote this feature entirely for the multi-device capabilities that it would offer, I don't care much about local history.