Rendered at 23:43:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
NichoPaolucci 13 days ago [-]
“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
rozab 13 days ago [-]
One of the most annoying quirks of LLMs for me is the insistence on, after being corrected, loudly noting what wasn't done. After getting it to change something stupid in code, it will leave a comment in the code boasting about how it doesn't do the stupid thing, which to future readers reads like an 'asbestos free!' label on a cereal box.
evan_ 13 days ago [-]
I’ve left so many PR reviews in the last few months that are essentially “this looks good but delete 80% of the comments.”
munk-a 13 days ago [-]
Lets assume one of two worlds - one where AI is constantly improving and one where the tooling is a dead end. In the first world the AI generated comments are no better than the commentary that would be generated in the next six months - in the second world the AI generated comments will obscure the human written comments.
In what world are AI generated comments actually value adds?
evan_ 13 days ago [-]
If the AI (or the person) ran into a non-obvious constraint, or some externality, or there’s a plan that just isn’t implemented yet- then the comment wouldn’t be able to be divined by the AI. But yeah just pointing the AI at something and saying “write me docs” will get you something at best equally good as what’s going to be available.
victor_edka 13 days ago [-]
this. like I feel that even telling sonnet 5 to explicitly not add comments it still produces them even on suppa simple logic
colechristensen 13 days ago [-]
One of the reasons this is there is the "psychology" of the LLM performs better with these kinds of affirmations. If you've made a mistake once you're likely to make it again, so leave a note.
This indeed pollutes the code with a bunch of nonsense. One of the things I have it maintain instead is a "findings" document with lessons learned and such.
aozgaa 13 days ago [-]
> If you've made a mistake once you're likely to make it again, so leave a note.
In my experience the comments behave as a form of prompt injection. The llm makes a conceptual mistake, writes it in a comment, and now subsequent agents make the same mistake!
pkulak 13 days ago [-]
Usually for me it writes a test to verify that the stupid thing isn’t happening.
orisho 13 days ago [-]
I have a contrarian take on this: if most people working on the codebase are using the same model, then these comments serve a very useful purpose: they tell the model's future self that despite its tendency towards this solution, it is incorrect and here's why. It encodes useful context right when the model needs it next to avoid making the same error.
I imagine this style of commenting is partially responsible for model improvement in SWE work, a trained trait through feedback, since it makes the comments actually useful. Not to you or me, but to an LLM.
Some of these errors are obvious to a human, that's why we find the comments unnecessary. But if everyone's using LLMs and said model tends to make this error, then they are very useful. It's like a comment you would leave for another human to help them avoid a footgun. It's just a LLM footgun, not a human one.
sander1095 13 days ago [-]
I agree, but that information should be in the commit, which the model also has access to. Of course it's more token intensive to look through commits, but "good" models might know when some more research about a particular bit of code they find weird would be a good idea. Thoughts?
cromka 13 days ago [-]
It doesn't necessarily have to go through commits, it can do bare git blame to see if something stands out. But otherwise agreed.
dasil003 13 days ago [-]
The problem is that the list of things one shouldn't do is infinite. The things one should do are narrow and get narrower along two independent axes of clarity/wisdom: system requirements and engineer seniority. LLMs overindex on any words given, so you only want to give them negative guidance around truly repeated, almost common-sense pitfalls. But in a large distributed system often the changes come from all different angles, and each agent will find it's own unique failure modes. Those comments will dilute critical context for diverse agents far more than they will help on average, at least for the systems I'm working on, given current claude code chattiness.
One way to clear some of the low-hanging slop is to just have a separate agent code reviewing and pruning any comments that don't stand on their own purely in the context of the diff, but it still doesn't catch it all.
vips7L 13 days ago [-]
If LLMs are any good, like many of you claim, they won’t need these comments. They will ingest the code and know what was done. They won’t need comments about what wasn’t done.
YonathanTesfaye 13 days ago [-]
Ha ha fair. But yeah shelling out to git and reusing the original tree object was deliberate means file contents can't change even if I screw up elsewhere.
whateveracct 13 days ago [-]
why can't anyone just do things themselves anymore? it's all LLM crap
danudey 13 days ago [-]
For what it's worth, I've used Claude to write a lot of smaller utility tools that I wouldn't normally have the time to sit down and implement, but which also solve straightforward problems.
One small example is an extension for the `gh` cli where I give it a PR number and multiple branches and it cherry-picks that PR to those branches, or lets me know if some of the branches don't work. For managing multiple release branches it's very handy, but not so handy that I would have spent a lot of time and energy doing a good job of it.
This seems like a similar sort of thing - a user friendly way to do something that most people don't need, and most people who need it probably don't need it very badly.
I haven't used claude to replace my actual skills - researching, solving problems, etc. - but I do use it to replace all the stuff which is essentially 'spend a few hours reading API docs and writing boilerplate code'.
whateveracct 13 days ago [-]
but if you were sharing those utilities - even in a github gist! - why not write the English parts for human consumption yourself?
gritzko 13 days ago [-]
That is in fact the difficult part. You have to explain it all coherently while adjusting to the reader's frame. No one does that for no good reason. It is hellish work.
saghm 13 days ago [-]
git has a notoriously overcomplicated interface, so this is a scenario that I can honestly understand why someone wouldn't want to do it by hand
whateveracct 13 days ago [-]
but what about the writing English to describe it part? does English also have a notoriously overcomplicated interface lol
arscan 13 days ago [-]
Well, yeah, it does.
Effective and clear communication is really important and often really hard for engineers. It is said that one goal of stackoverflow was to help programmers learn how to write through practice, as it’s both very hard and very critical to their effectiveness:
But programmers are also lazy*, so why put in the effort to improve when you can just get llms to do the work for you?
* not necessarily in a bad way
saghm 13 days ago [-]
I mean, given that the English you wrote above didn't make it clear that was the only part you were complaining about, it's worth it to consider that maybe precision is hard in natural language regardless of how it's written
whateveracct 13 days ago [-]
it is pretty clear in context given what i was responding to
InsideOutSanta 13 days ago [-]
Maybe I'm misunderstanding, too, but it seems to me that most people responding to you misunderstood your point.
saghm 13 days ago [-]
I certainly didn't read it the way they intended!
qurren 13 days ago [-]
They can, just in today's world, they just are not deemed impressive enough by the voting public to make it to the front page.
whateveracct 13 days ago [-]
that's troubling..
MattGaiser 13 days ago [-]
A tool like this never sees the light of day without an LLM. Git is complicated and use case for this is rather niche.
matheusmoreira 13 days ago [-]
I'm reverse engineering a cherished video game from my childhood. I got to the audio engine part and things got pretty difficult. Managed to map out the locations of the audio data but figuring out which song was which was going to take a long time.
Claude somehow wrote a bespoke one-off Python script to play back the songs straight out of the ROM. I give it the ROM and a hexadecimal address and it just plays it. Converts the data from the ROM into PCM audio samples and pipes them over SSH into termux on my phone where they are played back via SoX play.
Yes, Claude wrote a literal sound synthesizer so I could do this. Claude painstakingly tuned the goddamn synthesizer too, he tweaked it over and over again until the output sounded right based on annoyingly human feedback like "these notes are supposed to be in the background but they are too loud".
This tool turned a painstaking reverse engineering task into a nostalgic listening experience that brought literal tears to my eyes. I mapped out every single song in the game this way.
Without LLMs, none of this would ever have happened.
keybored 13 days ago [-]
> Without LLMs, none of this would ever have happened.
That would have been better for the world.
keybored 13 days ago [-]
“Editing” commits is not niche, and editing metadata like dates seems to come up a few times for a fair few number of people.
You can already expose the commit object as the headers (metadata) and the commit message. That’s like a spreadsheet: change these columns and we will make a new commit. That changed format can then be persisted as a commit object. So.
> A tool like this never sees the light of day without an LLM.
Are LLMs memory holing all the numerous tools built around Git (with git(1) or without)? There was already a query-Git-like-SQL tool before The Age of LLMs. I never tried that, but was that simpler to implement than this tool? Edit: Okay, maybe it wasn’t “niche” so that’s the differentiator.
whateveracct 13 days ago [-]
i definitely used to write bash functions for this sort of thing tho. no GUI, but it was useful to do stuff like obscure my working hours (make it look like i did personal stuff after-hours. make it seem like stuff took all day instead of an hour..like adding sawdust to meat).
like you said, niche and probably unnecessary. and if i were to have published them (even in a gist!) i would have written the docs myself instead of forcing people to read LLM-speak. That's just lazy.
gritzko 13 days ago [-]
Yep, tell Claude to spit out a shell script. Use Python if bash is not enough.
whateveracct 13 days ago [-]
It wasn't hard to just..figure it out though. One sitting tops.
Claude is learned (taught? lol) helplessness, at scale. I'm pretty sure it's their real moat.
gritzko 13 days ago [-]
If you dont use that regularly, why keep the app?
vips7L 13 days ago [-]
People are lazy.
voidfunc 13 days ago [-]
Because I have better things to do with my time.
whateveracct 13 days ago [-]
I have better things to do than read LLM prose copy-pasted verbatim too.
And yet here we are. I have to read LLM design docs that turn into LLM PRs with LLM PR descriptions and comments and docs.
wavemode 13 days ago [-]
Offtopic but, it always amuses me that the words "provably" and "probably" are one letter apart (and I frequently misread them for each other).
Myzel394 13 days ago [-]
Why would you think such a project would reimplement git?
mminer237 13 days ago [-]
I believe that was sarcasm.
13 days ago [-]
13 days ago [-]
Defletter 13 days ago [-]
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.
TiddoLangerak 13 days ago [-]
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.
Defletter 13 days ago [-]
The author date was when it was introduced to Parliament, the commit date is the date of Royal Assent. Ditto with the date a referendum was called versus when its results were certified, etc.
lrvick 13 days ago [-]
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
YonathanTesfaye 13 days ago [-]
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.
That sure helps for personal use cases, and interesting!
If you have more than one author in the history though that won't work, but I imagine where this is used the most is by an author cleaning up their own PRs.
Appreciate being heard on this sort of thing! Will take a closer look.
iamcoder18 13 days ago [-]
This is cool, but has anyone ever needed to rewrite commit authors or dates?
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.
fmorel 13 days ago [-]
git-filter-repo is amazing for the second case. I've used it to split repos and rename folders multiple times.
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.
schainks 13 days ago [-]
If someone's been committing with a bogus email address and they're still working on the project, shouldn't they clean up their own commits?
blazarquasar 13 days ago [-]
Yeah, using this tool for example?
throwaway613746 13 days ago [-]
[dead]
webstrand 13 days ago [-]
Usually its me who has been committing with a bogus email address, because I don't like having my real user/email set in my $HOME/.gitconfig
xp84 13 days ago [-]
Hi there, webstrand@Webstrands-MacBook-Pro.local - we meet again!
f1shy 13 days ago [-]
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
icase 13 days ago [-]
yes; when i wanted to make it look like i didn’t procrastinate for a week and implement the entire feature in one day
dgunay 13 days ago [-]
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.
ClikeX 13 days ago [-]
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.
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.
13 days ago [-]
gaws 13 days ago [-]
> has anyone ever needed to rewrite commit authors or dates
Yes. Plenty of times.
13 days ago [-]
beart 13 days ago [-]
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.
skinfaxi 13 days ago [-]
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
globular-toast 13 days ago [-]
To be fair, it does really look like a photo of a monitor.
skinfaxi 13 days ago [-]
I didn't think that at all. There weren't even any lightning artifacts or glare or anything.
Conscat 13 days ago [-]
I thought it was a semi-transparent window until I read this. The curvature makes that clear, wow!
gcr 13 days ago [-]
There is no curvature in the screenshot, only a semitransparent background
YonathanTesfaye 13 days ago [-]
it is a actually a screenshot, that's zorin's window transparency doing that
GinsengJar 13 days ago [-]
Look again.
unqueued 13 days ago [-]
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.
Hmmm, this seems to be making easy something you normally should not do.
Carrok 13 days ago [-]
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.
slashdave 13 days ago [-]
Spreadsheet? that's a meat cleaver, not a scalpel
YonathanTesfaye 13 days ago [-]
that's it
YonathanTesfaye 13 days ago [-]
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
nkrisc 13 days ago [-]
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.
YonathanTesfaye 13 days ago [-]
that was the idea
jauntywundrkind 13 days ago [-]
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!
Please put up this or another screenshot as the first thing you see in the README - please!
I'm reluctant to clone a repository and spend time on it just to find out the project looks crap and I don't want to use it. A screenshot saves other people's time :)
YonathanTesfaye 13 days ago [-]
done
everybodyknows 13 days ago [-]
Unreadable in iPad Safari -- delayed popup darkens the screen and demands app install.
YonathanTesfaye 13 days ago [-]
ah that's imgur. moved it to a github-hosted image should be fine now.
esafak 13 days ago [-]
I'd put that in the repo not here.
YonathanTesfaye 13 days ago [-]
you're right, done
no-name-here 13 days ago [-]
Thanks, but is that a photo of a screen instead of a screenshot and that’s why it looks cloudy/random splotches are brighter?
Regardless, it’s better than nothing, thank you.
vivzkestrel 13 days ago [-]
- 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
YonathanTesfaye 13 days ago [-]
noted
f1shy 13 days ago [-]
I would like to see something like this in magit. Other there is already?
YonathanTesfaye 13 days ago [-]
No idea not an emacs person does magit handle bulk author/date edits or just reword? genuinely curious
sixtyj 13 days ago [-]
Extra points for the name.
YonathanTesfaye 13 days ago [-]
Appreciate it! pick a commit, stab it
sixtyj 13 days ago [-]
Slicing or cutting fat is imho better ;)
hootz 13 days ago [-]
Would be great to have this, but as a TUI tabular editor.
ffsm8 13 days ago [-]
its vibecoded. just point another vibe based harness at it and youll have it in an hour or two. this thing is as trivial as you can get get, scope wise
YonathanTesfaye 13 days ago [-]
[dead]
dhruv3006 13 days ago [-]
that's a catchy name - good luck.
YonathanTesfaye 13 days ago [-]
thanks
YonathanTesfaye 13 days ago [-]
I built a small Tauri app that just shows your commits in a table and lets you edit message/author/date directly, plus find & replace with regex if you need to fix a bunch at once. It backs up the branch before it rewrites anything doesn't touch file contents, just metadata.
Glad the LLM noted this - I was worried this would reimplement git
In what world are AI generated comments actually value adds?
This indeed pollutes the code with a bunch of nonsense. One of the things I have it maintain instead is a "findings" document with lessons learned and such.
In my experience the comments behave as a form of prompt injection. The llm makes a conceptual mistake, writes it in a comment, and now subsequent agents make the same mistake!
I imagine this style of commenting is partially responsible for model improvement in SWE work, a trained trait through feedback, since it makes the comments actually useful. Not to you or me, but to an LLM.
Some of these errors are obvious to a human, that's why we find the comments unnecessary. But if everyone's using LLMs and said model tends to make this error, then they are very useful. It's like a comment you would leave for another human to help them avoid a footgun. It's just a LLM footgun, not a human one.
One way to clear some of the low-hanging slop is to just have a separate agent code reviewing and pruning any comments that don't stand on their own purely in the context of the diff, but it still doesn't catch it all.
One small example is an extension for the `gh` cli where I give it a PR number and multiple branches and it cherry-picks that PR to those branches, or lets me know if some of the branches don't work. For managing multiple release branches it's very handy, but not so handy that I would have spent a lot of time and energy doing a good job of it.
This seems like a similar sort of thing - a user friendly way to do something that most people don't need, and most people who need it probably don't need it very badly.
I haven't used claude to replace my actual skills - researching, solving problems, etc. - but I do use it to replace all the stuff which is essentially 'spend a few hours reading API docs and writing boilerplate code'.
Effective and clear communication is really important and often really hard for engineers. It is said that one goal of stackoverflow was to help programmers learn how to write through practice, as it’s both very hard and very critical to their effectiveness:
https://blog.codinghorror.com/how-to-write-without-writing/
But programmers are also lazy*, so why put in the effort to improve when you can just get llms to do the work for you?
* not necessarily in a bad way
Claude somehow wrote a bespoke one-off Python script to play back the songs straight out of the ROM. I give it the ROM and a hexadecimal address and it just plays it. Converts the data from the ROM into PCM audio samples and pipes them over SSH into termux on my phone where they are played back via SoX play.
Yes, Claude wrote a literal sound synthesizer so I could do this. Claude painstakingly tuned the goddamn synthesizer too, he tweaked it over and over again until the output sounded right based on annoyingly human feedback like "these notes are supposed to be in the background but they are too loud".
This tool turned a painstaking reverse engineering task into a nostalgic listening experience that brought literal tears to my eyes. I mapped out every single song in the game this way.
Without LLMs, none of this would ever have happened.
That would have been better for the world.
You can already expose the commit object as the headers (metadata) and the commit message. That’s like a spreadsheet: change these columns and we will make a new commit. That changed format can then be persisted as a commit object. So.
> A tool like this never sees the light of day without an LLM.
Are LLMs memory holing all the numerous tools built around Git (with git(1) or without)? There was already a query-Git-like-SQL tool before The Age of LLMs. I never tried that, but was that simpler to implement than this tool? Edit: Okay, maybe it wasn’t “niche” so that’s the differentiator.
like you said, niche and probably unnecessary. and if i were to have published them (even in a gist!) i would have written the docs myself instead of forcing people to read LLM-speak. That's just lazy.
Claude is learned (taught? lol) helplessness, at scale. I'm pretty sure it's their real moat.
And yet here we are. I have to read LLM design docs that turn into LLM PRs with LLM PR descriptions and comments and docs.
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
https://github.com/TheRealYT/git-knife/releases/tag/v0.2.0
If you have more than one author in the history though that won't work, but I imagine where this is used the most is by an author cleaning up their own PRs.
Appreciate being heard on this sort of thing! Will take a closer look.
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.
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.
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
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.
Yes. Plenty of times.
Haven't seen mentioned, but you might want to check out https://github.com/mystor/git-revise
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.
I'm reluctant to clone a repository and spend time on it just to find out the project looks crap and I don't want to use it. A screenshot saves other people's time :)
Regardless, it’s better than nothing, thank you.
- i should be able to change order of commits
- i should be able to change what files went in a previous commit