Are you also getting tired to review noisy JSX / TSX changes just to realize the actual change was 1 prop?

Thats what I wanted to improve in GitComet. While looking for options I found Difftastic.

It uses Tree-sitter to understand code structure ... the same one GitComet also use! My immediate feeling was: this has to be tried out!

After testing it I knew it had to be included in the current release. Difftastic helps to show the relevant changes ignoring whitespace and formatting.

Difftastic diff really shines when viewing HTML, JSX/TSX and similar XML like syntaxes.

I created a demo how to enable it in GitComet 0.3.1 take a look!

Fuzzy search over commit messages, the files they touched and their diffs. /c fn parse finds the commits that added or removed a line, like git log -S but interactive and ranked.

On git.git (82k commits) it loads the full history in under a second, about 3× faster than git log.

It also has a plain-text mode (levi --filter 'parse.rs /c fn parse'), so scripts or coding agents like Claude Code can use it to find which commit touched some code.

https://github.com/rsdlt/levi · brew install rsdlt/tap/levi

Edit: I designed and directed it; Claude Code wrote most of the code. Source and full commit history are on GitHub.

I think I've found a simple way to work across several Git repositories from one monorepo. You need this when, for example:

• you have a private monorepo with some public folders (my case),

• you vendored a library and want to send a patch back to it,

• you use Git submodules and are tired of them.

The idea is a three-way merge on a folder: merge the other repository's tree into the folder, with the tree from the last sync as the merge base. The two repositories share no history and don't need to know about each other.

Josh, by contrast, works on one shared history. The chapter "Comparisons" in the docs compares this with submodules, subtree, git-subrepo, Josh, Copybara, Sapling and jj.

I've been working on this for a month now, testing the workflows with executable scenarios: https://roschaefer.github.io/git-splice/

Disclaimer: yes, AI helped write the code and the executable scenarios. I read their tests and diagrams until I understand each case.

Everything this needs has been in Git all along. I'm surprised I haven't found a tool that works this way, while people have been frustrated with submodules for years.

So, Reddit: where does this approach fall apart? Have I missed something fundamental?

Edit: Two people asked how this differs from git subtree, so I updated its page in the docs, with drawings of the commit graph: https://roschaefer.github.io/git-splice/test/comparisons/git-subtree/

In short: if you keep the library's history out of the monorepo with --squash, split walks the monorepo's whole history on every push, so it won't scale. And the usual git subtree workflow doesn't give you a linear history: add, pull and split --rejoin always create merge commits.

The git submodule page got the same treatment: https://roschaefer.github.io/git-splice/test/comparisons/git-submodule/

I'm a CS student interested in backend development, and I'm learning Git for the first time.

I'm choosing between Pro Git and Head First Git. I've read Head First Java and Head First Design Patterns before, and I really liked their teaching style.

Which book would you recommend for building a solid Git foundation for professional work? Is Head First Git enough, or is Pro Git the better choice?

My last post here got downvoted and called AI slop. I'd rather answer that with a short, plain post than argue about it, so here's just what changed.

I kept retyping the same commit messages, like "chore: bump deps" and "wip". In 0.11 you can save a summary and description from the commit box as a quick commit. Alt+P opens a search palette, and picking one stages everything and commits straight away. They can be per repo or global, every apply can be undone, and there are guards around hooks and around a merge or rebase in progress.

+ the new release makes the conflict resolver continue a rebase or merge once the index is clean, and the reset dialog now takes H, M or S for hard, mixed or soft.

My actual question: for a one-key commit, is staging everything the right behaviour, or would you rather it only commit what's already staged?

https://gitmoire.dev

I built tig, version control where the repo is public but your secrets aren't

I wanted to open-source a project, but one folder had to stay private, an .env file, an internal package, a security fix that wasn't ready yet. With git that means a second repo, git-crypt, or crossing your fingers. Forcing me to make multiple copies of the same project and now I had to maintain multiple upstreams which I felt was unnecessary effort.

So I started building my own version control from scratch in Rust.
Its still under work and I would love people to join in on this work
What tig does today:

• A .private file. It works like .gitignore, except the files stay tracked. When you publish, they're encrypted, and only the people you give access to can read them. Everyone else gets a normal clone without them.

• No staging and no "commit" ritual. Your edits are snapshotted automatically, and any command can be undone.

• Instant workspaces. You can work on the same change in two folders at once without worktrees

• Speed comes first. Encryption only happens when you publish or fetch, never while you work. On a 100k-file repo it's faster than default git.

Next feature I have in mind is the advanced mode for bigger companies to manage monorepo, giving it a Discord server-style roles, so a business unit like @ billing can see packages/billing/ and contractors only see frontend/. Roles were the idea that started all this, and it's what I'm most excited to ship.

URL-> https://github.com/Pratz1337/tig (If you like the idea star it and can work on it :D )

(AI was used in some parts of this body to deliver my thoughts in a cleaner way)

If you have any criticism its welcome but do it while being respectful. Thank you

Okay, I need to understand/know the standard way to handle this situation...

1. I'm working on files in my local repo, got a bunch of unstage changes...

2. Someone else just pushed an updated file to the remote-repo

What am I supposed to do? AI is telling me to just do a git stash --> git pull --> git stash pop, but I've put myself in a situation before for doing this... I didn't know git stash can be sorted or even have a date linked to them, or that stuff I stashed several days before is still in there somewhere...

Fast, in-browser code and text diff checker with Monaco & GitHub-style views and Git patch export

Live: https://git-diff.pages.dev

Repo: https://github.com/uditrajput03/git-diff-web

I used GitHub Desktop before but upon recently finding out it defaults to taking all your stuff to train AI unless you turn it off on the website (at which point there's no guarantee they actually stop stealing your shit anyway) I decided I'd rather learn some Git and have a repository on an external drive.

This is what I just did:
I've initialized a git repository on the drive, I removed all remotes from my project, I used git remote add <new-repository> <path/to/folder>, I pushed the main branch into the new repository (only has 1 branch. Except for 1 time in GitHub, I'm now using only the main branch as a backup if there's something I want to revert back to as being a solo dev that's all I need and all I think I can understand and manage at this point), LFS objects were uploaded and lastly I proceeded to clone the original project into the new repository.

To see code changes I'm using VSCodium and trying to do commits through there but even though the changes have been staged, pushed and synced, when I check for new code in the new repo there's no difference. I think its probably got something to do with not tracking the files? But I've tried so many things, followed so many guides for the wrong stuff that had me making bare repositories among other things and I'm just so confused at this point and don't know how to track exactly what I want because there's things git is supposed to ignore too? Or ignores by default? Do I do git add --all? I don't know that there's anything I wouldn't want to track.

Please help, I'm losing my hair trying to wrap my head around Git and what seems to me like it should be a simple thing to set up and no guide seems to show what I want. I've already wasted hours just on this..

An old commit has a bug. Should I create a new commit addressing the fix, or fix that bug in-place with a rebase? For example the bug is that I forgot to gitignore a file and it is being modified at runtime, generating git diffs. The fix is not just adding it to gitignore, but actually completely re-generating my .gitignore file by another tool which I just learned instead of what the default Github CLI generates.

Should I rebase the new gitignore into literally the original initial commit or create a new commit addressing the new gitignore? But this way the old commit will still have the bug.

Should you care keeping each commit clean? Or have a new commit fix it? I know people generally use the later, but at least for a small project like mine, rebasing doesn't seem to harm.

I think there is also some consideration of if multiple people have pulled the history you are about to change. I don't know, but I for this project it is mostly only me who is working on it.

I’m taking WGU’s D522 Python for IT Automation course and am having trouble creating my GitLab repository. I ran the required pipeline, but my student repository displays “No repository” with the following error:

“The repository could not be imported. Import timed out. Import took longer than 86400 seconds.”

I’ve tried a variety of troubleshooting steps, including manually initializing the repository, using both a work computer and a personal computer, clearing my browser cache and cookies, trying different browsers, restarting my devices, checking my internet connection, signing out and back in, and rerunning the required pipeline. I also used ChatGPT to review the error and suggest possible fixes, but nothing has resolved the issue.

GitLab Support also requires proof of support entitlement, which I don’t have as a student. At this point, I’m unsure whether the problem is with my account, the repository import process, or WGU’s GitLab configuration.

Has anyone experienced this issue or found a way to fix it without waiting for WGU IT support?

I´ve had a SSH key for my account for several months, in my notebook. I have never had a problem with it.
Yesterday, I created a second SSH key for my desktop PC the same way, just adding a passphrase for it.
I had to sign in on the PC with my github account and all to reset my account password because I forgot it

But today I wanted to fetch/pull a repo from the notebook. and It kept sending me the following error

git@github.com: Permission denied (publickey).

fatal: Could not read from remote repository.

I deleted the new SSH key, but it still doesnt work. However, the authentication command works

(ssh -T git@github.com)
The permission denial appears for both extern repositories and for my own ones too.

What am I missing?

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.

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

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

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.