Version history (git based)

Plugs and Libraries
1

Hello, I created a version history plug to navigate between git-tracked versions of a page.

Screenshots

dark
dark1920×930 182 KB

light
light1920×930 174 KB

About this plug

I tested this on SilverBullet v0.10.4 and v2, but it’s pretty new so you may find bugs.

The plugin should be safe to use since I purposely didn’t add any action or
code that could change your pages, you may find problems here but hopefully
nothing destructive.

Installation

Want to try it out? you can go to the repo.

The url for the plug is:

ghr:ivanalejandro0/silverbullet-history

Check out the SilverBullet docs on how to install it. Note that it’s different on v0.10.4 than on v2.

Caveats

  • this will only work if your space is in a git repo and only with the files you have versioned.
  • the history won’t work if you’re offline, I haven’t tested nor investigated much that use case.
  • I haven’t yet tested how this behaves with page renames. I don’t think it’ll show a good history on that use case.
  • The history shows a linear history, but git history can be like a tree, this UI is pretty simple and if you do a lot with git you may not get the best picture of the history.
  • Commits can have different authors but I’m not showing that information. I imagine most people edit their notes by themselves so showing the author information would be redundant.
13 Likes
2

This looks pretty cool!

1 Like
3

thank you! awesome - helps a lot!

1 Like
4

This is actually very nice!!
Only one thing I’m missing is some kind of “diff” between two versions :slight_smile:

1 Like
5

I use git regularly with code, so I definitely see the appeal of seeing the diff.
I think that showing some kind of diff would take the plug to a next level, but I would need to think about how the UI for diffs would look like for it to be intuitive for everyday users.
The diff would need to be text only since mixing diff with a proper page render may not be feasible.

The goal for the versions UI is for users to be able to recover old changes.
What would you expect to get from a diff?

I think that I’d like to just click through versions and see what that version changed from the previous and see how the file “evolved” over time, but kind of do that with the current UI already.
Other users may need to find the date or context for certain change and that would be better served by a git blame.

I’ll give it some time and see what people that use this for a while feel that is missing before making any substantial changes.

6

I’d love to be able to diff two pages, so that I can resolve conflicts better. But not sure if that fits with the purpose of this particular plug.

7

I have had just one simple conflict long ago so I don’t have much of an opinion here.

But yeah, I don’t think there’s a need for git or versions to diff two conflicting pages, I think that could be its own separate plugin.

8

The conflicting pages are a pretty good use case, but as Stan mentioned, it is not really related to the plug.

However, having a diff would make it way better to see what changed between different versions of a page coming from the git history plug.

But, to be honest, it’s not a must-have of course, but nice to have :wink:

9

I’ve put together a widget that lists all conflicted pages (if any), with simple links to view the diffs. When you navigate to a specific diff page, it shows the diff itself along with buttons to either delete the conflicted page or apply the diff (which replaces the original page).

I’m happy to share it if anyone is interested. Just a heads-up: since it deletes pages and can overwrite the original when applying a diff, there’s some potential risk involved if something’s not working as intended.

That said, it seems to be working quite well for me so far - haven’t run into any issues yet.

2 Likes
10

Sounds very interesting. I would be happy to test it :slight_smile:

1 Like
11

I want it !!! hahaha

1 Like
12

V2 compatibility issue?
index.plug.js:28 Lua error Error: Parse error at pos 5245
at index.plug.js:1:1234
at index.plug.js:1:1282
history.plug.js:1 Uncaught (in promise) Error: Unable to parse string provided to editor.navigate as ref
at history.plug.js:1:955
at history.plug.js:1:1003
history.plug.js:1 Uncaught (in promise) Error: Unable to parse string provided to

13

This seems to be the problem

14

Right, @ivanalejandro0 any chance you can change the prefix used to something else, since using @ in page names is no longer allowed as of the 2.0 release.

15

Oh, sure! I’ll make some time in the next few days to work on this. I haven’t had the time to update my instance to v2 yet so I didn’t caught it.

Any suggestions on what a better/proper prefix or path should be? I initially used “@” to prevent any “collision” with existing pages, something like I imagine was done for search page (“:magnifying_glass_tilted_left: search term”) on v0.10.4. Now on v2 I see is “search: search term”.

Maybe I’m not even asking the right question, I need to catch up with the latest on v2 and I’ll figure out a fix or come back with more questions :slight_smile:

16

Good question. Perhaps you can use history:? I now tend to use search: and tag: for such use cases.

Btw @MrMugame: this plug is actually using the ability to extend the FS from “plug space”, so good I didn’t remove that :slight_smile:

1 Like
17

It could be interesting to migrate It to space-lua and merge It with git lua script and have a full featured git space-lua script.
There are currently many scripts about git:

  • lua git bye @zef
  • a fork with more git commands
  • git history

We have to find a way to collaborate on space lua scripts to have high code quality and full featured components. It will be nice to externalize to space lua library.

18

I got it working with “history:”. I don’t quite like how it’s “history%3A” on the url bar but it looks good on SB’s ui.

this plug is actually using the ability to extend the FS from “plug space”

is the FS extension the readFile operation on pageNamespace?

  readFile:
    path: operations.ts:readFile
    pageNamespace:
      pattern: "^@History"
      operation: readFile

I’m actually working on using an event now since for some reason those operations were not working any more and I couldn’t find what changed on the apis since last time I tried it (on v2 beta 5 months ago).
I couldn’t find how to debug the problems of those operation seemingly not firing, luckily there’s an alternative.

I’m using this now and seems to be working fine

  readPageHistory:
    path: ./operations.ts:readFile
    events:
      - editor:pageCreating

(inspired from silverbullet/plugs/search/search.plug.yaml at main · silverbulletmd/silverbullet · GitHub )

The only thing I couldn’t get to work now is history links. On 0.10.4 and v2 beta, the getFileMeta (I think) was providing information about links so I could have a link pointing to the history of a file, but I don’t know if there’s a specific event that would help there now.

Anyways, I’m still putting time here and there to get it done soon. It does take a while since there’s not really much documentation of how to do the things I want to do, so I read SB’s code and other plugins for inspiration.

19

It could be interesting to migrate It to space-lua […]

When I started the plugin, around 5 months ago, there was SilverBullet 0.10.4 and v2 beta. I did try to do this using lua initially, maybe it was too early on the lua side or maybe skill issues on my part, but it became a mess really quick.
I remember struggling the most with putting contents on the LHS pane. I found much easier to deal with html+css+js on the typescript files of the plugin than on a silverbullet page.

Recently I’ve seen other people doing really cool stuff with lua… so I’m sure things are much easier now and it could be possible.

Personally, before trying to make something the size of this plug in lua, I’d like to see how the developer experience (maintaining the code on an editor, handling versions, managing assets like extra html/css/js files if needed) is, compared to using typescript on an external repo.

We have to find a way to collaborate on space lua scripts to have high code quality and full featured components. It will be nice to externalize to space lua library.

Maybe this was the goal of Awesome Libraries ?

20

Yes you could check Marp plug : markdown presentation rendering If It can help you.
I will try to externalize m’y space-lua scripts to “awesome Space lua scripts” but i need to understand how It’s possible to débug and develop without commit and push every to an external repository.
Good Luck for your migration and your plugin is awesome

1 Like