Playground! Updated (local) glib2 package to 2.88.1, GTK4 to 4.22.4 and libadwaita to 1.9.0.
With those in place I can checkout latest GNOME sources, so far a few already up and running with the latest being Gitte 0.5.0.
Not production ready (got some annoying bug in GTK4 where keystrokes are repeated eg pressing p resolves to pppppp....
Anyway, basics are good so far. 😇
🚀 #Gitte 0.5.0 is out!
- Signed commits & tags (GPG, SSH & X.509)
- Signature validation in the commit log
- Signing status helper
- Collapse-all / expand-all in stash view and commit log view
- New Cornish (kw) translation, thanks to @pigeon_
Also included:
- Overhauled dialogs
- Refresh handling based on IO activity
- Fixes & dependency updates
Flathub: https://flathub.org/en/apps/de.wwwtech.gitte
macOS: https://gitlab.com/dehesselle/gitte_macos/-/releases/v0.5.0+24
Repo: https://codeberg.org/ckruse/Gitte
#Gitte question.
Im am currently implementing commit and tag signing. I have it rudimentary working when running directly in the host system, but not when running in a flatpak environment.
To get it working there I would've to bundle gpg, gpgsm and ssh (for ssh-keygen)
That would make a really big bundle and a big maintenance burden.
What do you think I should do?
Given two branches, main and feature. Now you want to merge feature into main, with the strategy „rebase, then fast forward“. What is your expectation how the branch feature should look like after this operation?
Github (and the other forges, too) leave the feature branch in a rebased state. But there you normally delete the branch afterwards and just create a new one.
But what is the expectation for a desktop application? I am really not sure how I should handle this.
Christian Kruse
Begasus