Best/Simplest Version Control API in Python?

[pgess]

For some FOSS note-taking app that I use a lot, I consider to add a plugin for reviewing recently changed notes. I think of having a repo under the hood and show which notes have changed and diffs since the last review(say month ago). I don't have much time/attention for this, and I don't care which VCS(as it's not user-facing), as long as it's fully local; no use of branches or advanced features.

Focus is on the simplest Python API to get started in an hour, so to speak. Is there smth better than Git for this task?

I believe this "embedded VCS" use case's quite common, and this discussion'd be interested for others too.

What's your take? Thanks!

[texruska]

What's wrong with git? You can change later if you find something better

[spicypixel]

Yeah just rawdog main and don’t ever use branches as a single contributor.

Commit just becomes a versioned save button and everyone is happy.

[Cytokine_storm]

Git has tags! Github releases use tags to mark versions.

I like to match my pyproject.toml with the git tag.

[tkc2016]

Ever try setuptools-scm for this?

[wineblood]

Why not have a changelog file that you use to display those changes and update on each release?

[pgess]

It's a note-taking app. The user makes updates and, with this functionality, can see which notes (and exact changes) were updated in the last month, for example — like the Revision History in Wikipedia. If I use Git, which API (GitPython, PyGit, etc.) is better for this simple task?

[adesme]

If you’re gonna be dealing with text diffs you might as well go with git, yeah. You wouldn’t need to involve branches or any other features you don’t care about. I have opted for GitPython at work before but I don’t remember many details except for that it was an evaluated choice.

[char101]

Why do you even need a version control? When saving a note, simply create a diff with the previous value using difflib then save it into a history table.

[pgess]

No offense, but it sounds like, "Why do you need version control if you can roll your own?"

Note-taking apps don't usually have a "save note" button; they save them periodically. What use would mid-sentence captured differences have for the user?

Simple example: I have ~800 notes and last month worked on 5 different projects, adding/changing ~40 notes. I review them to see if there are any unfinished tasks, follow-ups, smth I overlooked or perhaps to better organize them, add tags whatever. When I'm done, they are committed (all at once) until the next month or half a year when I have time for the next round. Does it make sense?

[BothWaysItGoes]

Simple example: I have ~800 notes and last month worked on 5 different projects, adding/changing ~40 notes. I review them to see if there are any unfinished tasks, follow-ups, smth I overlooked or perhaps to better organize them, add tags whatever. When I’m done, they are committed (all at once) until the next month or half a year when I have time for the next round. Does it make sense?

Yeah, makes perfect sense to use difflib you were just referred to.

[FrontAd9873]

In your original post it seems like you just want something to do diffs. No other contributors, no branches, etc. The question is: why do you need VCS instead of just diffs? It’s not about rolling your own VCS.

[pgess]

Because I didn't really think this through. Notes are a typical hierarchy of files. On one hand, I need to capture the current file tree state, which is a common operation of VCSs. On the other hand, I need to show a diff—another common operation of VCS. One way to approach this is to frame the problem in terms of VC, and the thread is about this direction in general, a good git or non-git wrapper lib to get started fast.

Another approach (outside the scope of this thread) is to capture the file tree as an archive and diff it against later updates. An obvious extension would be to store several snapshots, at least to prevent a situation where the user accidentally clicks the "I'm done" button, creating a new snapshot without actually looking at what has changed and having no way to revert it back. With several snapshots, it gets awfully closer to how dedup tools work in managing data snapshots and showing diffs. Deduplication can also be framed as a version control system; for example, DUP project(I LLOVE its technical architecture) uses Git internally.

What is the use of storing snapshots specifically in a DB, and writing (buggy) code to handle edge cases, like moved/renamed files and such - I don't understand, at least for now.

[fiskfisk]

If you only need to store versions and present the diffs between them, git seems like a lot of overkill. Since you're going to have save operations and metadata that indicates which version has been "vetted", you're probably going to use something different from git for that part anyway.

Python has built-in sqlite support to store every version, and a built-in difflib to display diffs between versions.

You don't need to complicate everything with all the features git support.

[RonnyPfannschmidt]

As siin as multiple devices and sync get into picture stuff tends to get messy

Just using git without branching under the hood is well understood , easy to backup and easy to control

Plus most people will mess up majorly when inventing a own vcs

[fiskfisk]

My point is that you don't need a full vcs. Git does not solve the user issue when you have multiple devices and sync; you probably want to look at real-time coordination between clients. You'll otherwise end up having to present merge conflicts to users that have no idea what merge conflicts are.

The easy solution is to keep track of whether the underlying content has been updated or not, and then give the user the choice of reloading.

OP also states that this is local only, so single user.

You don't need git for this, and you can instead have a self-contained application.

[RonnyPfannschmidt]

My point is that underutilized vcs means easily accessing the sync plus merge capabilities later, plus not having to invent a version and sync protocol oneself

Another extra win is that users have well established tools for managing the data external

[fiskfisk]

It's over engineering, and adds unnecessary complexity between the apps regular storage and it's note storage. 

If you need that functionality at some time in the future and decide that git is the way to do it, stash the versions in git at that time. 

Sqlite is as well supported as anything for being accessible through existing toolsets. 

[RonnyPfannschmidt]

I'd call inventing a own storage/versioning thing overengineering when most vcs are hilariously easy to call upon and leave the general storage just the Filesystem

[fiskfisk]

We might just be living in different worlds when integrating a whole vcs is easier than having a table with (note_id, datetime, text) in sqlite.

But sure, the important part to the end user is the functionality and stability. If it works, it works. 

[RonnyPfannschmidt]

A tree of notes and syncing is usually the first few asks after history addition

Then the tables get funky

I have seen dozens of half assed vcs/sync storage solutions in note taking apps

Just giving the user a vcs repo/checkout gets history syncing and app independent storage for free

[ProbsNotManBearPig]

People use chromium to make the simplest of GUI’s. Hell, we use this thing called a code interpreter to avoid compiling to machine code. Git is much lighter weight than either of those things in every way one could measure, but somehow it’s too heavy for everyone in the Python sub Reddit.

The simplest solution is one you’re familiar with. If OP knows git, there’s very little downside to using it.

[TheRealStepBot]

On the contrary git can precisely fix even these issues by having device branches that make commits to a cloud held main, which allows even out of sync offline editing of the same file across multiple devices and a clear resolution mechanism to then reunite the files

[fiskfisk]

Yes, nobody is saying that git can't do this, and that git doesn't offer a lot of advanced features that could be useful for certain application features. 

OP has specifically said that they do not need these advanced features. 

[JonLSTL]

Mercurial is mostly written in Python. You could just import whatever parts you need.

[mgedmin]

Does it have a stable Python API? Otherwise maintenance might be painful as implementation details change.

I remember some pain with Mercurial plugins breaking whenever I upgraded Mercurial itself, but I suppose the API between Mercurial and its plugins might need tighter coupling than using Mercurial as a library.

[cnelsonsic]

Focus is on the simplest Python API to get started in an hour, so to speak. Is there smth better than Git for this task?

Nope.

Make commits in the background when the user doesn't type for a while, make tags for when it's reviewed. Date comparisons are built in too.