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

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

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.

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!