I've always found submodules fragile and unergonomic, especially when switching branches and adding or removing them frequently. git-subrepo's model (vendored code as plain files plus a .gitrepo marker) fixed that for me, but I didn't like its ergonomics, conflict resolution and error handling.

git include keeps that model as a git plugin, shipped as a single compiled binary built on libgit2. It reads and writes the same .gitrepo format, so existing subrepo directories work without migration. It never creates temporary branches or worktrees, and the ergonomics, including conflict resolution, match working in a plain git repo. When you want to contribute changes back upstream, it rebuilds a history from the parent repo commits that touched the vendored directory, so they arrive as clean commits. It also supports vendoring specific tags or commits, Git LFS, nested includes, and a migrate command for converting submodules.

You only need the plugin to add, update or contribute back to a vendored repo. Anyone who just clones the project, or patches vendored code without contributing the changes upstream, doesn't need it at all. A plain git clone gives them everything, which keeps the initial setup of your project straightforward.

Binaries are available for all major platforms, including distribution via conda-forge.

I used Claude during development, as is common now, but would not consider the project to be AI slop. It solves a problem I encountered while working on my own projects, and I take full responsibility for all major design decisions. Issues and feature requests are welcome.

https://github.com/Flova/git-include

TL;DR: git include is a git plugin and a .gitrepo-compatible superset of git-subrepo that should improve the UX of working with nested or vendored git repos.

Edit: I didn't format the post correctly

You can play around and see what types of objects git creates in the background as you make commits. Despite being a software engineer for like 10 years, I never took the time to really pick apart the object model. It's actually more straightforward than git-scm* makes it seem.

Here's the blog post: https://app.learngit.io/blog/whats-inside-a-git-commit/

\ No shade to the official docs, I consult them religiously. I'm just more of a visual learner, especially for the more complex stuff.*

In Git, commit timestamps (GIT_COMMITTER_DATE and GIT_AUTHOR_DATE) are completely client-controlled strings. Anyone can forge commit history with a single flag:

`git commit --amend --date="2021-01-01 12:00:00"`

Because Git blindly records whatever the client clock claims, raw Git commit histories are legally treated as uncorroborated hearsay under U.S. Federal

Rules of Evidence (FRE 802). In ownership disputes, co-founder litigations, or M&A tech diligence, opposing counsel or auditors can easily argue that backdated commits were fabricated.

To solve this without breaking standard Git muscle memory or leaking private code, I built **GitProof** (https://gitproof.legendrail.com) and open-

sourced its standalone verifier (https://github.com/LEGEND-Rail/gitproof-verify):

### How it works under the hood:

1. **Deterministic Merkle DAG Hashing:** Before a push, it walks the Git tree and computes a canonical SHA-256 Merkle root across all tree and blob

objects. Changing a single character in any file completely alters the 32-byte Merkle root. 2. Atomic RFC 3161 Notarization: It sends only the 32-byte hash imprint to qualified public Time Stamp Authorities (DigiCert & Sectigo) via HTTP POST. Zero source code leaves your local machine. 3. Cryptographically Signed CMS Tokens: The TSA binds the hash to an atomic clock timestamp and cryptographically signs it using their intermediate X.509 certificate authority. 4. Git Hook Automation: A native .git/hooks/pre-push hook intercepts pushes to automatically seal and append attestations into .gitproof/proof. json. 5. 100% Open & Offline Verification: In legal or compliance audits, closed-source tools destroy credibility. The standalone verifier (gitproof- verify) is a zero-dependency Go CLI that anyone can run offline to verify Merkle trees and certificate chains against root CAs.

### Quick test in any Git repo:

```bash
# Install CLI
curl -fsSL https://gitproof.legendrail.com/install.sh | bash

# Seal commit & notarize against DigiCert TSA
gproof seal --notarize

# Verify cryptographic proof offline
gitproof-verify proof.json

• Open-Source Verifier Repo: https://github.com/LEGEND-Rail/gitproof-verify • Detailed Technical Spec: https://gitproof.legendrail.com/docs/rfc3161.html

I’d love to hear your thoughts on Git hook ergonomics, Merkle tree performance on large repos, and how teams here handle code provenance!

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

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 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?

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?

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 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.

The live server is still my old tui style repo listing it was a lot harder than I thought to implement a file content viewer

Hi r/git. Disclosure up front: I made this, it's free, and I'm here for criticism more than upvotes.

It's called gitmoire. It's a desktop Git client (Rust + libgit2 underneath, not shelling out to git for everything). I built it because the client I was using took almost 40 seconds to open on my machine and wanted me logged in. gitmoire is a 14 MB download and opens in under 5 seconds for me. Your numbers will differ.

I tried to do fewer things well rather than everything. The parts I'd most like feedback on from people who know Git deeply:

• Worktrees: a manager for sibling checkouts, an install script that runs in each new one, and each worktree gets its own hue so you can tell them apart.
• Conflicts: both sides with line numbers, take a whole side or single lines, and the result is a live editor. Nothing touches your files until you hit Mark resolved.
• Merges default to real --no-ff commits when you drag a branch onto another. Curious if people think that's the right default.
• Bisect on the graph and a reflog browser that restores lost commits as recovered/<short> branches (new in 0.9.0).
• Stash and WIP show up as nodes on the graph instead of a hidden list.
• Identity profiles live in repo config, never your global gitconfig.

There's also an optional AI side (off by default, uses your own CLI or local Ollama) that can split a messy working tree into atomic commits for you to approve. Happy to talk about that, but I know it's not why most of you are here.

Things I deliberately left out: in-app PR review, telemetry, accounts.

macOS, Windows and Linux. Builds aren't notarized yet, so expect one OS warning. The source isn't public right now; it's a hard fork of angkorGit, which is MIT.

https://gitmoire.dev

What would make you switch from the CLI, or what would stop you?

I found forgejo which is a self hostable Github alternative and radicle which is a P2P github alternative. I want to know of there is a way to host code on a forgejo instance or on radicle and publish a package in any of these package platforms...

• npm (CSS/JS)
• packagist/composer (PHP
• go/golang packages
• crates (Rust)
• pub.dev (Dart/Flutter)
• scoop (Windows apps)
• homebrew (MacOS apps)
• apt (Debian/Ubuntu apps)
• Nix (Linux apps)
• flatpak (Linux apps)
• f-droid (Android apps)

Would prefer to use open source git platforms over closed source github.

Heya!

I've been working on a little project called Weaver, a lightweight, native Git desktop client that I built because I wanted something to replace GitHub Desktop.

It's written in Zig using a new, super fast GUI library called KnotsUI, so there's no Electron or webview involved.

It supports all the usual Git operations, but also lets you organise repositories into groups, rename them, set custom icons, customise themes and accent colours, and quite a bit more.

I built most of it using Claude Opus 5.5, and it's been a really interesting project to work on, especially experimenting with Zig and KnotsUI.

It's completely open source, and I'd love to hear what people think! Feedback, suggestions and contributions are all very welcome.

GitHub: https://github.com/KeoneSomers/Weaver
Stars always appreciated!

At this moment, it can parse activity from Github and Gitlab. In future, i plan to add Forgejo and Gitea.

It generate two SVG files: last year activity and 2026 year activity, and simple HTML page with this two diagrams.

You can auto update this diagrams by using Github Actions. An example workflow for this i add to repository's README.

https://github.com/aguilam/git-activity

One of the things I encountered when I was working on my AI harness was the sheer number of branches and worktrees that were getting created, and how tools like go-git started struggling

I wrote this article/video on how I worked around it.

TLDR:

- clean up your branches

- pack your git objects

- and write some tooling in your system so you actively maintain this

Article · Video

Hi r/git,

I wanted a lightweight way to inspect Git commit topologies without running Docker, Node.js, or heavy Electron apps.

Inspired by the clean node canvas in n8n, I built a zero-server visualizer using pure Python (standard library only) and Vanilla JS / HTML5 Canvas.

**Key highlights:**

- **Zero dependencies:** Single Python script parses `git log` and `git status` into static data. No pip/npm packages.

- **n8n Canvas UI:** Bézier curves, dark mode, and a "Lane 0" backbone (master highway) to keep branches organized.

- **Built-in Diff Drawer:** Click any commit node to inspect syntax-highlighted unified diffs and changed files.

- **Runs entirely offline:** Opens directly in your browser via `file://`.

The project is open source on GitHub under **skszone01/n8n-git-ui** (I also attached a screenshot to this post).

Curious to hear what you think of the visual layout and lane routing!

https://github.com/skszone01/n8n-git-ui

Lately AI agents have started creating many work trees within a single repository. We noticed this is becoming a painful to review and follow.

We are trying to make it better by introducing "Workspaces" to GitComet, it combines native multi-window support allowing you to organize your repositories and work trees into logical groups.

You can give Workspace a custom theme so each window becomes clearly recognizable.

Under the hood we also optimized rendering and memory usage - because worktrees share a lot common git information so even if you have tens of work trees open same time it should not raise memory that much anymore.

There are also many other new improvements and changes, you can find those from Github as always.

Its been almost a year now and we are close to our community goal of 1000 stars! ;)

We would love to hear your feedback to help develop the product further!
Thanks, Havunen