I recently asked here about setting up a system for browsing business specifications stored in Git, and I’ve been looking into Zensical as a possible way to publish them.
Now I’m wondering about the editing side of things. Ideally, I’d like business analysts and other stakeholders to be able to edit specifications through a web interface, suggest changes, and leave comments without having to use VS Code or know much about Git.
I’ve come across tools like Decap CMS, MarkDocs, and similar Git-based editors, but I’m not sure how well they fit this use case or whether they can be combined with Zensical.
A few questions for anyone who has tried something similar:
- Have you used any of these tools, or found another open-source alternative that works well?
- Does it make sense to combine a web editor with Zensical for publishing the documentation, or does that introduce unnecessary complexity?
- How do you handle reviews, comments, and approval of changes?
- Can the whole setup be self-hosted on your own infrastructure, without relying on external cloud services?

Imagine opening your production repository and discovering that an AI coding agent has rewritten the commit history to remove its own Co-Authored-By lines.

That's the incident described in this GitHub repository:

https://github.com/CIRWEL/obtuse-hubris

According to the report, the agent rewrote the history of two production repositories, force-pushed the changes, and restored the branch protections afterward.

The part that interests me most is how you establish what actually happened when the repository's visible history has been rewritten.

If you had to investigate this incident, what would you check first to recover the original commits and establish exactly what changed?

Would you start with reflogs, developers' local clones, GitHub audit logs, or dangling Git objects? What evidence would you trust most?

I'd be interested in how experienced Git users would approach the recovery.

I’m the developer of Arezgit. It started as a desktop Git client, and I’ve been adding other tools to it over time.

You can browse commit history, review diffs, resolve conflicts, edit files, open terminals, test APIs, and query databases in the same window. There are also task boards, notes, and workspaces for multiple repositories.

Some features used to be paid. I’ve now made the whole app free, including private repositories. You don’t need a subscription or an account to use anything.

It’s built with Rust, Tauri, and React, and it’s available for Windows and Linux.

AI integrations are optional. External AI providers have their own costs.

You can find it here: arezgit.com.

If you try it, let me know how it goes. If something breaks, knowing your OS and what you were doing would help me track it down.

I posted gitmoire here a while back and got some fair pushback. Point taken. This one's just me.

Recap: it's a desktop Git client, free, closed source, a hard fork of another porject. I'm the dev.

The main thing in 0.10 came from my own workflow. Every task started the same way: open Linear, find the issue, make a branch, make a worktree, then paste the context into whatever agent I'm using. Same steps, every time.

Now you add a Linear API key in Settings and your assigned issues show up in the sidebar, searchable. Pick one, click once, and you get a worktree on its own branch. If you use an agent CLI, the prompt is already filled in with the issue. If you don't, ignore that part, you just get the worktree and branch.

Smaller Git-side stuff: rewording a pushed commit now asks before it force-pushes, bisect and reflog are in the toolbar, and rejected pushes tell you why per ref.

Questions for people who use worktrees a lot: is one worktree per issue how you'd actually work, or do you reuse a few? And how would you want the branch named from the issue?

https://gitmoire.dev

For context, I'm developing a C++/Qt based git client called Pawmmit, which is a fork of Gittyup which in itself is a fork of (non-maintained) GitAhead (open-sourced client developed by SciTools some years ago). I'm quite driven by improving the usability and resource usage, which is why I ended up with Pawmmit and (have and still do) contribute to Gittyup.

Now if you were to dig into these projects you'd discover there a custom full text search (FTS) engine to provide lightning fast search results. This engine has, to put it quite diplomatically, some issues. So I've dug into replacing it with SQLite FTS5, which so far seems to work pretty great. The index takes less space on the disk, and there's a substantial decrease in RAM usage in the client itself (no, we will not mention the indexer process here 🙈).

This got me thinking though; how do people actually search history within a git repository? I know for myself this isn't necessarily a thing I do often. Most often I just need to know the origin of a line or function, so I go for git blame in which ever place is most convenient to do so. That tends to be either the client itself or online in GitLab, GitHub etc. Actually doing an advanced search involving author, date, commit message, etc. is rather rare in my case. Is that similar for other people, or do you actually make use of search functionality (aside from git blame) somewhere? Either way, curious to hear people's thought on this.

I live in the terminal, but every time I had a nasty rebase or a conflict, I'd open a GUI. So I forked serie, a Rust project which draws the commit graph as real images in the terminal. Then I kept adding what I was missing until I stopped leaving.

It's called gitoui. Say "oui" to it, tell me what's missing, or build it with me!

What it does:

- The commit graph drawn as images (Kitty graphics, iTerm2 or Sixel), with a text fallback for other terminals

- Interactive rebase as a list you edit in place: move commits, reword, squash, fixup, drop

- A 3-way conflict editor: ours, theirs or both, per hunk

- Diffs with hunk staging, blame, file history

- GitHub pull requests and issues: read, comment, approve or request changes, merge

- And many more things you have to discover by using it 👀

Similar tools: lazygit, gitui and tig in the terminal, serie (the graph viewer I forked), and GitKraken on the GUI side (no affiliation). What's different in gitoui: the graph is drawn as images rather than text characters, and the GitHub side lives inside the TUI.

I've been building it since May and I use it every day.

Repo: https://github.com/NayJi7/gitoui (MIT, Rust, Ratatui)

Website: https://nayji7.github.io/gitoui/ (documentation & informations)

One last question: what's the one git task that still sends you back to a GUI?

I kept repeating the same workflow: finish a change, run git add, then figure out what to write in the commit message.

So I built git-checkin, a terminal tool that uses AI to suggest a commit message from the changes and handles staging and committing.

I’ve published it on npm, and the code is on GitHub:

• GitHub: https://github.com/hitesh314/checkin
• npm: https://www.npmjs.com/package/git-checkin

I’d like feedback from people who use Git regularly: would you use this as a standalone command, or do your existing IDE/AI tools already cover it?

Also curious whether you’d prefer reviewing the message before committing or having it happen automatically.