HN Debrief

Show HN: Git-knife – edit commit messages, authors, and dates like a spreadsheet

  • Developer Tools
  • Programming
  • Open Source
  • AI

Git-knife is a Tauri desktop app for rewriting Git history through a table view instead of interactive rebase or custom scripts. It lets you edit commit messages, authors, and dates, plus run regex find-and-replace across many commits. The author stressed that it does not reimplement Git. It shells out to the system Git CLI, rebuilds commits with `git commit-tree`, reuses each commit’s existing tree object, and makes backup branches plus `git-notes` markers before rewriting. The practical pitch landed: this is not for everyday version control, but for local cleanup before a push, especially when you need to fix a bad email address, a broken clock, or a batch of metadata mistakes.

If your team ever cleans up commit history, this points to a real usability gap around Git’s rewrite tools. Treat tools like this as pre-push surgery only, and keep signed or shared histories out of scope unless you are ready for branch resets and signature loss.

Discussion mood

Cautiously positive. People liked the niche utility, the name, and the choice to lean on Git’s own plumbing instead of reinventing it. The hesitation was not about the feature itself so much as where it is safe to use, especially around shared history, signed commits, and the amount of LLM-generated presentation cruft.

Key insights

  1. 01

    Real use cases go beyond vanity edits

    They grounded the tool in workflows that are hard to do cleanly with raw Git commands. Reconstructing historical projects, splitting a repository while preserving per-file provenance, and fixing mistaken credit all depend on editing metadata accurately, not cosmetically. The mention of `git-filter-repo` also sharpens the boundary. Git-knife is convenient for targeted commit surgery, but heavier repository reshaping already has mature specialist tools.

    Use a GUI editor when you need to fix a handful of commits or run batch metadata cleanup. Reach for `git-filter-repo` or similar tools when the job is structural, like carving a subdirectory into its own repo with preserved history.

      Attribution:
    • simonw #1 #2
    • fmorel #1
    • ClikeX #1
    • dgunay #1
  2. 02

    Signed history is the hard limit

    Rewriting metadata is not just socially risky. It is cryptographically destructive for signed commits. New commit objects mean new hashes, so existing signatures stop verifying, and a history signed by multiple authors cannot be rewritten without losing that trust chain. That turns this from a general history editor into a tool for unsigned branches or pre-publication cleanup.

    If your org relies on signed commits for provenance, keep tools like this off shared branches. Put policy and tooling around that now, before someone assumes a metadata-only rewrite is harmless.

      Attribution:
    • lrvick #1
  3. 03

    Backup branches and git-notes are the right safety rails

    The safety story is stronger than the UI pitch. Using a dedicated backup namespace means recovery is built in, and `git-notes` gives you a way to annotate rewritten history without polluting commit messages. That is the kind of operational guardrail history editors usually skip, and it makes the project feel more like careful Git plumbing than a novelty frontend.

    If you build internal rewrite tools, copy these protections. Automatic backup refs and notes are cheap insurance when the entire workflow depends on destructive history edits.

      Attribution:
    • unqueued #1
  4. 04

    Dates are sometimes data, not just theater

    Several comments made the obvious joke about hiding procrastination, but the better point was that commit dates can carry meaning in archival or reconstructed repositories. When Git is used as a ledger for external events, the right timestamp is part of the record. That makes date editing legitimate in a narrow class of repos where history is documenting something that happened elsewhere.

    Do not assume commit timestamps are always disposable developer metadata. In archival, legal, or reconstructed datasets, decide whether dates are evidence before you let people rewrite them casually.

      Attribution:
    • iamcoder18 #1
    • xp84 #1
    • f1shy #1
    • unqueued #1
    • icase #1
  5. 05

    LLMs make niche utility software more likely to exist

    The most practical defense of the project’s AI-assisted origin was economic, not ideological. Small internal-grade tools often solve real annoyances but do not justify a polished hand-built implementation. LLMs lower the cost enough that these one-evening utilities get built and shared instead of living as half-broken shell snippets on one person’s laptop.

    Expect more narrow workflow tools to show up now that the build cost is lower. Judge them on architecture and safety, not on whether they were possible to write by hand.

      Attribution:
    • danudey #1
    • MattGaiser #1
    • voidfunc #1

Against the grain

  1. 01

    LLM-written docs make small tools feel disposable

    The strongest pushback was not anti-tool so much as anti-presentation. Copy-pasted AI prose and boilerplate comments make readers trust the project less, because they signal that the author optimized for output volume over careful explanation. For a niche tool that already asks users to rewrite history, that trust penalty is real.

    If you publish a developer tool, rewrite the README, screenshots, and comments in your own voice before shipping. Presentation affects whether people will risk running it against important repositories.

      Attribution:
    • whateveracct #1 #2 #3
  2. 02

    Interactive rebase already solves much of this

    For people comfortable with Git, `git rebase -i` already acts like a compact spreadsheet for history cleanup. The value here is not new capability. It is a friendlier interface layered on top of existing mechanics. That limits how novel the tool is, especially for experienced Git users who already have muscle memory.

    Do not replace established Git workflows for power users just because a GUI exists. Use tools like this to broaden access for teammates who avoid history editing today.

      Attribution:
    • jauntywundrkind #1
  3. 03

    First impressions can derail a technically sound project

    A surprising amount of attention went to whether the screenshot looked like a phone photo of a monitor. It turned out to be a real screenshot, distorted by desktop transparency, but the reaction still matters. Sloppy-looking visuals can drown out substantive design choices, even when the implementation is careful.

    For developer tools, fix screenshots and onboarding polish early. People often decide whether a project is serious before they read the architecture notes.

      Attribution:
    • beart #1
    • skinfaxi #1
    • YonathanTesfaye #1

In plain english

force-push ↩
A Git push that overwrites remote branch history instead of fast-forwarding it.
Git ↩
A distributed version control system used to track changes in code and other files over time.
Git CLI ↩
The Git command-line interface, meaning the standard terminal commands provided by Git.
git commit-tree ↩
A low-level Git command that creates a commit object directly from an existing tree and parent commits.
git-filter-repo ↩
A specialized tool for rewriting Git repository history, often used for tasks like splitting repos, removing files, or renaming paths across history.
git-notes ↩
A Git feature for attaching extra annotations to commits without changing the commits’ contents or hashes.
interactive rebase ↩
A Git workflow that lets you reorder, edit, squash, or reword commits before finalizing rewritten history.
LLM ↩
Large language model, a machine learning model trained to predict the next token in text.
regex ↩
Short for regular expression, a compact pattern language used to search and replace text.
Tauri ↩
A framework for building desktop applications using web technologies with a lightweight native shell.
tree object ↩
A Git data object that records the directory and file snapshot for a commit without the commit metadata itself.

Reference links

Git history rewrite tools and guides

Examples of reconstructed Git history

Writing and documentation

  • How to Write Without Writing
    Cited in a side discussion about why engineers struggle with the English parts of documentation and often offload them to LLMs.