8 ms·

Highlights from Git 2.54

156 points by ingve 6mo ago

samtrack2019 6mo ago
the new git history command seems to be useful for quick reword, altho since i use lazygit/magit i don't really see much of a problem to me
- olejorgenb 6mo ago
  Wish reword took a commit range though
  - yencabulator 6mo ago
    I had to check and `jj describe` does. You get all the commit messages in a single file to edit, with headers separating them.
ajoberstar 6mo ago
Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-scm.com/docs/git-history https://git-scm.com/docs/git-history https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-split https://www.jj-vcs.dev/latest/cli-reference/#jj-split
- aulin 6mo ago
  Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
  - roblabla 6mo ago
    jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
    - locknitpicker 6mo ago
      > In jj, everything rewrites the history (...) Surely that isn't true, otherwise it would be completely unusable for auditing.
      - baq 6mo ago
        it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
      - kps 6mo ago
        It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple). Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense. Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
      - BeetleB 6mo ago
        By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches. But ... is it really that different from git? You can always rewrite history in git, correct?
  - skydhash 6mo ago
    Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit. ‘jj describe’ lets you add a message to a commit as it’s not there by default.
  - deleted 6mo ago
    [deleted]
  - auscompgeek 6mo ago
    describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
  - baq 6mo ago
    in jj the history has mutable and immutable commits.
- wakawaka28 6mo ago
  If this is meant to be a dig, you should keep in mind how much jj owes to git.
  - IshKebab 6mo ago
    I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism. It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. Some software has crap UX or missing obvious features (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!
    - locknitpicker 6mo ago
      > It's very widely remarked that the Git CLI is pretty miserable, (...) You hear some very vocal critics expressing hyperbolic personal opinions on the topic, but I find that in the majority of the cases the opinions aren't objective or grounded on reality. It's just people whining. The litmus test is asking what is the worst example of this "pretty miserable" CLI they talk about. More often than not it's just baseless nitpicking. I recommend you give the litmus test a try to see how far this myth flies.
      - WorldMaker 6mo ago
        I feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain". There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.) That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.) That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain". It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.
- NewsaHackO 6mo ago
  jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.
  - baq 6mo ago
    what has one to do with the other...?
    - codygman 6mo ago
      I'll consider avoiding jj because of this, personally.
      - NewsaHackO 6mo ago
        It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.
        gucci-on-fleek 6mo ago
        Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.
- chrishill89 6mo ago
  Yeah it’s a direct inspiration.
- semanticc 6mo ago
  It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).
ufo 6mo ago
I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?
- sethops1 6mo ago
  > what workflows have worked best for you to get everyone to run the hooks By running the linters and any other checks on CI instead.
  - baq 6mo ago
    autoformatter and autofix linter results can be committed and pushed by CI into the PR branch itself. this is a pain sometimes, but as a repo owner it should protect your sanity.
    - skydhash 6mo ago
      I just add a check workflow that test that the files are well formatted and linted. If it passes, one of the key things I check are changes to the configuration. Some tools allows for bypass comments, so I keep an eye out for those too.
    - sgarland 6mo ago
      Yep. Nothing I hate more than some trivial formatting error that could easily fix itself halting CI. I am all for consistent formatting and linting, I just think it should be silently handled without fuss.
  - IshKebab 6mo ago
    As well, not instead. Just add `pre-commit run -a` to your CI. Job done. It's still annoying for new contributors though because they might not know how to set up pre-commit (which was quite a pain until recently because it's written in Python).
WhyNotHugo 6mo ago
The new additions to `git add -p` seem pretty neat. Staging changes with `-p` is seriously underrated!
jinushaun 6mo ago
`git history reword` is great. Using `git rebase -i` just to fix a spelling error is overkill and doesn’t actually do what I want.
- jauntywundrkind 6mo ago
  Why doesn't it do what you what? I hate to be the worry wart, but I am worried folks are going to avoid `git rebase -i` even more now. It is such an excellent excellent UI in my opinion: it shows you the history of what is clearly, and let's you modify it as you please!
  - NekkoDroid 6mo ago
    > Why doesn't it do what you what? If you have anything else branching/referencing a commit after the reword commit that isn't part of the branch you are rebasing you now have all those references still pointing to the old commit and need to go through every one of them to fix them.
    - WorldMaker 6mo ago
      Which is a reminder that maybe `--update-refs` should be the default for `git rebase -i`. It's great that it is now going to be the default for both `git replay` and `git history`, and I know why git is conservative in updating defaults, but at some point there's a benefit to updating the defaults. (I'd also argue that `-i` itself should have long been the default for `git rebase`. Also, while we are at it, probably `--autosquash` should be default.)
greg_dc 6mo ago
Those new git history commands will save me an average of maybe a minute a day, but it's still definitely handy nonetheless! After 2 months, that's an hour back! The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.
Rover222 6mo ago
I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.
- ramon156 6mo ago
  I'd advise to do what you're doing, but to check the commands it runs and figuring out why it does these things. The first step is usally "what does git [command] do?" followed by `man git-[command]` and see what it does. That way you're still "blazingly-fast with your SOTA-LLM!!!" while also understanding why :)
  - Rover222 6mo ago
    huh? I know git commands. it's just a dead skill with LLMs. SQL too.
charles_f 6mo ago
git history makes me think of git revise^1, which gives you a bunch of handy tools to changes your history, move commits around, remove some of them, cut them (which git history now does). I found it very handy in the past 1: https://git-revise.readthedocs.io/en/latest/man.html https://git-revise.readthedocs.io/en/latest/man.html
everybodyknows 6mo ago
> ... rewrites any descendent branches to point at the updated history. But what about local heads referred to only by a "soft" tag? Is their history rewritten, or is it left to refer to the old history?
optionalsquid 6mo ago
Support for config based hooks is very nice. Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs. With this, I can just write a simple script to perform that check, and add it to my global config
the_duke 6mo ago
Config based hooks seem to miss the mark though? The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something? So not very useful at all... I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.
- WorldMaker 6mo ago
  This seems to be a first step in that direction, though. Merging repo suggestions into one per-repo `.git/config` is still a big improvement over N `.git/hooks/$EVENT` files. Plus the new config format is directly mergeable, whereas the old hooks files often weren't without extra work (they had to point to one and only one shell command, which might be an arbitrary binary rather than a mergeable shell script; hence why "hooks managers" are as much shell script managers as hooks file maintainers and often were generally mutually exclusive/do not cooperate). Obviously it still leaves the door open if there should be a `.githooks` or `.gitconfig` file in the committed worktree that can suggest changes to `.git/config` with fewer manual steps, but this first effort in minimizing the number of manual steps and simplifying those manual steps to a simpler merge is still quite useful. Which is also before pointing out that the `git config` command is already quite scriptable as a simple merge tool. You could in theory replace a "hooks manager" install script with just a sequence of `git config set --local hook.$name.*` lines. You still have to figure out how to get the user to run that script just like installing any other hooks manager, but that's an easy script now to write.
adregan 6mo ago
Excited for the new release! Though looks like `git history split` won't yet replace my typical workflow: $ git rebase -i // with e on commit in question $ git reset HEAD~ $ git add -p As I can't edit the hunk. `git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash). And I bet I'll get some use out of `git rebase --trailer`.
immanuwell 6mo ago
git history is a genuinely welcome addition - rebase -i has always been a sledgehammer when sometimes you just need a scalpel, and it's nice to see git finally acknowledging that not every history edit needs to be a whole production
Razengan 6mo ago
Is there any simple non-hacky way to "save" a snapshot of the working state, without clearing the working state like `stash` does? I sometimes go in too far deep with a bunch of changes that should be committed separately but need to be worked on together, and I need to save it occasionally in case of data loss etc, and the only way I have/know is the good old "compress entire folder to a .zip"

156 points by ingve 6mo ago

samtrack2019 6mo ago

the new git history command seems to be useful for quick reword, altho since i use lazygit/magit i don't really see much of a problem to me

olejorgenb 6mo ago
Wish reword took a commit range though
- yencabulator 6mo ago
  I had to check and `jj describe` does. You get all the commit messages in a single file to edit, with headers separating them.

ajoberstar 6mo ago

Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-scm.com/docs/git-history https://git-scm.com/docs/git-history https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-split https://www.jj-vcs.dev/latest/cli-reference/#jj-split

aulin 6mo ago
Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
- roblabla 6mo ago
  jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
  - locknitpicker 6mo ago
    > In jj, everything rewrites the history (...) Surely that isn't true, otherwise it would be completely unusable for auditing.
    - baq 6mo ago
      it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
    - kps 6mo ago
      It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple). Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense. Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
    - BeetleB 6mo ago
      By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches. But ... is it really that different from git? You can always rewrite history in git, correct?
- skydhash 6mo ago
  Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit. ‘jj describe’ lets you add a message to a commit as it’s not there by default.
- deleted 6mo ago
  [deleted]
- auscompgeek 6mo ago
  describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
- baq 6mo ago
  in jj the history has mutable and immutable commits.
wakawaka28 6mo ago
If this is meant to be a dig, you should keep in mind how much jj owes to git.
- IshKebab 6mo ago
  I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism. It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. Some software has crap UX or missing obvious features (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!
  - locknitpicker 6mo ago
    > It's very widely remarked that the Git CLI is pretty miserable, (...) You hear some very vocal critics expressing hyperbolic personal opinions on the topic, but I find that in the majority of the cases the opinions aren't objective or grounded on reality. It's just people whining. The litmus test is asking what is the worst example of this "pretty miserable" CLI they talk about. More often than not it's just baseless nitpicking. I recommend you give the litmus test a try to see how far this myth flies.
    - WorldMaker 6mo ago
      I feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain". There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.) That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.) That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain". It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.
NewsaHackO 6mo ago
jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.
- baq 6mo ago
  what has one to do with the other...?
  - codygman 6mo ago
    I'll consider avoiding jj because of this, personally.
    - NewsaHackO 6mo ago
      It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.
      - gucci-on-fleek 6mo ago
        Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.
chrishill89 6mo ago
Yeah it’s a direct inspiration.
semanticc 6mo ago
It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).

ufo 6mo ago

I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?

sethops1 6mo ago
> what workflows have worked best for you to get everyone to run the hooks By running the linters and any other checks on CI instead.
- baq 6mo ago
  autoformatter and autofix linter results can be committed and pushed by CI into the PR branch itself. this is a pain sometimes, but as a repo owner it should protect your sanity.
  - skydhash 6mo ago
    I just add a check workflow that test that the files are well formatted and linted. If it passes, one of the key things I check are changes to the configuration. Some tools allows for bypass comments, so I keep an eye out for those too.
  - sgarland 6mo ago
    Yep. Nothing I hate more than some trivial formatting error that could easily fix itself halting CI. I am all for consistent formatting and linting, I just think it should be silently handled without fuss.
- IshKebab 6mo ago
  As well, not instead. Just add `pre-commit run -a` to your CI. Job done. It's still annoying for new contributors though because they might not know how to set up pre-commit (which was quite a pain until recently because it's written in Python).

WhyNotHugo 6mo ago

The new additions to `git add -p` seem pretty neat. Staging changes with `-p` is seriously underrated!

jinushaun 6mo ago

`git history reword` is great. Using `git rebase -i` just to fix a spelling error is overkill and doesn’t actually do what I want.

jauntywundrkind 6mo ago
Why doesn't it do what you what? I hate to be the worry wart, but I am worried folks are going to avoid `git rebase -i` even more now. It is such an excellent excellent UI in my opinion: it shows you the history of what is clearly, and let's you modify it as you please!
- NekkoDroid 6mo ago
  > Why doesn't it do what you what? If you have anything else branching/referencing a commit after the reword commit that isn't part of the branch you are rebasing you now have all those references still pointing to the old commit and need to go through every one of them to fix them.
  - WorldMaker 6mo ago
    Which is a reminder that maybe `--update-refs` should be the default for `git rebase -i`. It's great that it is now going to be the default for both `git replay` and `git history`, and I know why git is conservative in updating defaults, but at some point there's a benefit to updating the defaults. (I'd also argue that `-i` itself should have long been the default for `git rebase`. Also, while we are at it, probably `--autosquash` should be default.)

greg_dc 6mo ago

Those new git history commands will save me an average of maybe a minute a day, but it's still definitely handy nonetheless! After 2 months, that's an hour back! The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.

Rover222 6mo ago

I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.

ramon156 6mo ago
I'd advise to do what you're doing, but to check the commands it runs and figuring out why it does these things. The first step is usally "what does git [command] do?" followed by `man git-[command]` and see what it does. That way you're still "blazingly-fast with your SOTA-LLM!!!" while also understanding why :)
- Rover222 6mo ago
  huh? I know git commands. it's just a dead skill with LLMs. SQL too.

charles_f 6mo ago

git history makes me think of git revise^1, which gives you a bunch of handy tools to changes your history, move commits around, remove some of them, cut them (which git history now does). I found it very handy in the past 1: https://git-revise.readthedocs.io/en/latest/man.html https://git-revise.readthedocs.io/en/latest/man.html

everybodyknows 6mo ago

> ... rewrites any descendent branches to point at the updated history. But what about local heads referred to only by a "soft" tag? Is their history rewritten, or is it left to refer to the old history?

optionalsquid 6mo ago

Support for config based hooks is very nice. Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs. With this, I can just write a simple script to perform that check, and add it to my global config

the_duke 6mo ago

Config based hooks seem to miss the mark though? The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something? So not very useful at all... I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.

WorldMaker 6mo ago
This seems to be a first step in that direction, though. Merging repo suggestions into one per-repo `.git/config` is still a big improvement over N `.git/hooks/$EVENT` files. Plus the new config format is directly mergeable, whereas the old hooks files often weren't without extra work (they had to point to one and only one shell command, which might be an arbitrary binary rather than a mergeable shell script; hence why "hooks managers" are as much shell script managers as hooks file maintainers and often were generally mutually exclusive/do not cooperate). Obviously it still leaves the door open if there should be a `.githooks` or `.gitconfig` file in the committed worktree that can suggest changes to `.git/config` with fewer manual steps, but this first effort in minimizing the number of manual steps and simplifying those manual steps to a simpler merge is still quite useful. Which is also before pointing out that the `git config` command is already quite scriptable as a simple merge tool. You could in theory replace a "hooks manager" install script with just a sequence of `git config set --local hook.$name.*` lines. You still have to figure out how to get the user to run that script just like installing any other hooks manager, but that's an easy script now to write.

adregan 6mo ago

Excited for the new release! Though looks like `git history split` won't yet replace my typical workflow: $ git rebase -i // with e on commit in question $ git reset HEAD~ $ git add -p As I can't edit the hunk. `git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash). And I bet I'll get some use out of `git rebase --trailer`.

immanuwell 6mo ago

git history is a genuinely welcome addition - rebase -i has always been a sledgehammer when sometimes you just need a scalpel, and it's nice to see git finally acknowledging that not every history edit needs to be a whole production

Razengan 6mo ago

Is there any simple non-hacky way to "save" a snapshot of the working state, without clearing the working state like `stash` does? I sometimes go in too far deep with a bunch of changes that should be committed separately but need to be worked on together, and I need to save it occasionally in case of data loss etc, and the only way I have/know is the good old "compress entire folder to a .zip"