Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I would like to see something like this in magit. Other there is already?
  • No idea not an emacs person does magit handle bulk author/date edits or just reword? genuinely curious
  • - make a drag and drop ui for git rebase

    - i should be able to change order of commits

    - i should be able to change what files went in a previous commit

  • noted
  • This looks cool! Are there screenshots available?
  • Two recent threads where I sing some praises of git rebase -i, specifically linking it to a spreadsheet. Awesome to see this pop up, feels serendipitous!

    Git rebase -i is not that scary 119 points, 16 days ago, 151 comments https://news.ycombinator.com/item?id=49053385 https://cachebag.sh/journal/interactive-rebasing/

    Staging patches with git add 34 points, 12 days ago, 52 comments https://news.ycombinator.com/item?id=49048570 https://cachebag.sh/journal/interactive-rebasing/

    Really enjoying jj these days but the git rebase -i spreadsheet remains such a winner. Expanding it more, leaning in, ftw.

  • Hmmm, this seems to be making easy something you normally should not do.
  • Based on the name I have to imagine the author knew this. A knife is a dangerous tool if used improperly, and invaluably useful when used properly.
  • Agreed mostly. The intent is local cleanup before you push like fixing a wrong author email across a batch or dates from a machine with a bad clock
  • So, exactly like a knife? Generally we don't want to cut people open, but when we need to do it, like during surgery, a sharp knife sure helps.
  • I appreciate that it uses git-notes and that is makes backup branches in it's own namespace. I wish it were a bit lighter though.

    Haven't seen mentioned, but you might want to check out https://github.com/mystor/git-revise

  • It looks like the screenshot was an actual photo of someone's monitor. I'm left wondering why print screen wasn't utilized. And for some reason it really makes me not want to touch this project.
  • Look again.
  • I thought it was a semi-transparent window until I read this. The curvature makes that clear, wow!
  • Looking at the metadata it says it is a Gnome screenshot. What a pointless and incorrect non-sequitor.

      exiftool -a -u -g1 ~/Downloads/screenshot.png
    
      ---- ExifTool ----
      ExifTool Version Number         : 13.55
      ---- System ----
      File Name                       : screenshot.png
      Directory                       : XXX
      File Size                       : 1260 kB
      File Modification Date/Time     : 2026:08:11 16:24:37-04:00
      File Access Date/Time           : 2026:08:11 16:24:41-04:00
      File Inode Change Date/Time     : 2026:08:11 16:24:41-04:00
      File Permissions                : -rw-r--r--
      ---- File ----
      File Type                       : PNG
      File Type Extension             : png
      MIME Type                       : image/png
      ---- PNG ----
      Image Width                     : 2351
      Image Height                    : 1388
      Bit Depth                       : 8
      Color Type                      : RGB with Alpha
      Compression                     : Deflate/Inflate
      Filter                          : Adaptive
      Interlace                       : Noninterlaced
      Significant Bits                : 8 8 8 8
      Software                        : gnome-screenshot
      Creation Time                   : Mon 10 Aug 2026 10:19:53 PM +03
      ---- Composite ----
      Image Size                      : 2351x1388
      Megapixels                      : 3.3
  • This is cool, but has anyone ever needed to rewrite commit authors or dates?
  • The few times I've wanted to completely rearrange a repo, It's been enough just make a backup branch and then dump the log from there and pull what I want.

    I have script somewhere I think it's called git-cherry-replace, which soft resets a commit id and copies the commit message and optionally populates GIT_COMMITTER_DATE and whatnot.

    What I described is probably simple enough that an LLM can implement it.

    But unless you're trying to retroactively reconstruct something to preserve the exact meaning, you should consider whether a rebase even makes sense.

  • Very rarely. But it can come up if you archive change history in git for things that aren't originally tracked in git.

    Take laws for example. Legalize[1] is a project that documents all laws into a git structure where each distinct change is a commit with the proper timestamp of tha change. Sure, this specific project builds that entire git history once and it's unlikely a retroactive change required such edits. But do something like this for historical sources where information is still coming in, and you might need to change a date when new findings occur.

    [1] https://github.com/legalize-dev/legalize

  • Times I have needed to do this:

      - An agent messed with my git config for some reason so I had to go back and fix the commit authorship
      - I created a PR mostly based on work that someone else did, so I reauthored most of the commits to be in their name
    
    I have never personally needed to touch dates.
  • yes; when i wanted to make it look like i didn’t procrastinate for a week and implement the entire feature in one day
  • Yes. Absolutely! Many times I had a wrong configured terminal and messed up the author. Often I work in different projects, privately and in my work, and I use different authors for both
  • Yes, for instance it could be useful if someone’s been accidentally committing with a bogus email address. Or if you’re cleaning up some sort of mess and would like to recreate an accurate history.

    Obviously as with any “force push” situation, the usual caveats apply if this is on a branch others have checked out, but if the mess is big enough, it is sometimes worth it to send everyone a script to reset or just to have people delete and re-check-out.

    by xp84
  • I've needed to do this for a bunch of reasons.

    1. Sometimes I do a scraping project where I want the commit dates to match when the data actually changed, reconstructed from sources like the Internet Archive or the dates on https://platform.claude.com/docs/en/release-notes/system-pro... - for example here: https://github.com/simonw/research/commits/main/extract-syst... - or this project that attempted to reconstruct the history of Tim Berners-Lee's original browser: https://github.com/simonw/1991-WWW-NeXT-Implementation/commi...

    2. Sometimes I split a Git repo into two, and I want to preserve the commit history (authors and dates) on the files that end up in the new repo - effectively replay the history of just one folder from the original to help create the new one.

    3. I occasionally mess up cleaning up and merging a PR from an open source contributor such that the work is incorrectly credited to me. I'll fix the commit so that it credits the right person.

  • Note: This will not work and cannot work on repos that use signed commits from multiple authors.

    Signed git history is immutable, and unsigned git history is a supply chain attack vector.

    That said I could see this being useful for single-author WIP branches doing cleanup before a PR

  • added a warning for this in v0.2.0 signed commits now flag before the rewrite, it can know resign rebuilt commits with your key.

    https://github.com/TheRealYT/git-knife/releases/tag/v0.2.0

  • This is, funnily enough, something I've been periodically searching for for nearly a decade, and even renewed my search yesterday. For those wondering, my use case is a model Parliament (context: https://news.ycombinator.com/item?id=43474850) and deciding on using git to store the laws, with the commits representing the Acts of Parliament themselves. The problem is that we need to guarantee that every commit has the correct metadata: we do not care at all about the conservation of commit hashes. And if we've accidentally missed a law and need to interactively-rebase it into the git history, it should NOT reset all the subsequent commit dates to the current timestamp. Basically, we're wanting to use git as a historical archive. I'm delighted to have found this.
  • Fwiw, in plain git, there's 2 dates associated with commits. The author date tells when the content was authored, and doesn't change with rebase. Only the commit date changes. So the correct metadata is already there, and even more precise. It can tell you both when it was authored, and when it's history was last changed.
  • “It never reimplements git — it shells out to the system git CLI and rebuilds commits with git commit-tree, reusing each commit's original tree so file contents are provably never changed.”

    Glad the LLM noted this - I was worried this would reimplement git

  • Why would you think such a project would reimplement git?