I agree, interactive rebasing existed for ages and git history is mainly a user experience improvement over it. This way of framing git history goes way past engagement tricks and erodes the blogger's credibility.

Still, it shows how incredibly broken the StackOverflow system is. It's completely normal for older answers to become outdated, but they still act like the old answers are laws of nature.

These answers are ~15 years apart, so the vote difference is not surprising.

I personally sort by ‘date modified (newest first)’ on StackExchange sites.

It’s now the 6th answer instead of the 20th, and if answers are sorted by Trending (which I recommend people do) in the dropdown, it’s currently 3rd.

It's not that roundabout compared to what `git history split` is doing. It's sort of the missing tool in a lot of the rebase discussions (in the Stack Overflow answers). Basically `git history split` is most useful for "split an older commit in this branch", so it's a higher level complex dance of, essentially:

- `git rebase -i`

- Change the TODO list to `edit` the chosen commit (everything else to `pick`)

- At the `edit` point:

  - (simplified) `git add -p`

  - `git commit`

  - `git add -u`

  - `git commit`

That "simplified" `git add -p` in the middle and that assumption that everything else not selected is the "other patch" is fine for quick splits, but there's still power user super powers in knowing the full rebase workflow and `git add -p`.

I think you'll find your workflow is still required. `git history split` is really only focused on turning a commit into 2 commits, so if you wanted multiple, you would need to run the command multiple times.

Add to that, it's patch functionality isn't as robust as `git add --patch`. For example, you cannot edit a hunk, so if you intended to tease out atomic changes, you won't be able to.

I do the same, but use `git gui` to select the changes.

You don't need --interactive. It is interactive by default.

Ah yes, I'll just pass that over to the compliance team and wait a few months for a denial.

I had a team that insisted on a linear history and was constantly rebasing things. This workflow strongly favors "just squash it all together" before a rebase to avoid re-resolving the same conflicts. This workflow often produces big patches that reviewers end up asking to be broken back up. This experience and a recommendation from my manager at the time made a good git GUI like sourcetree a daily driver for me. It's just second nature to review my own changes every time I stage files and quickly do a mix of staging whole files or "hunk-based", even allowing clicking to select specific lines within a hunk intuitively, rather than using the terminal UI and asking git to take a guess at splitting a hunk. I find a good git GUI invaluable, I have used sourcetree for years and love it. Unfortunately sourcetree isn't available for Linux, but I recently found SourceGit which seems to be a decent substitute.

Highly recommend trying a good GUI out, I think you would likely have similar ah-ha moments about workflow optimizations, and honestly I just cannot understand how people get by in git without a convenient way to visualize the commit tree (and yeah I know there is a decent command line treeview, but the context switching all the time in the terminal to go from viewing the tree or even the simple log to exit out and ask for commit contents just is so much more fussy and tedious).

Yes this is how jj does it, except that jj is more powerful because it does automatic rebase of all the downstream commits.

If you have any descendants of the gir history split (i.e. it's not the most recent) you'll have to do some more work (a rebase) to get back to a useful history. I think you can do this in the middle of an interactive rebase which is ok, but still not as easy.

My understanding is that `git history` was started after seeing jj, yes. I don't have a citation for you though, I could be wrong, that's just what I remember.

Please don't use LLM to write HN comments. To quote the guidelines[0], "HN is for conversation between humans".

[0] https://news.ycombinator.com/newsguidelines.html

Or the opposite direction, with repeated "git checkout -p ..." and commit steps. Slightly less comfortable because you have to figure out (such as from "git rebase --edit-todo") the later commit, but it makes testing the pieces easier.