The git history command

by turbocon • 9 days ago

456 312 9 days ago

nine_k• 9 days ago

In short, newer versions of git implemented three really frequent use cases of `git rebase --interactive` as separate lower-friction commands. Apparently they only work when there are no conflicts.

BobbyTables2• 9 days ago

Wonder if the history command is all that useful.

I prefer the interactive rebase and use it frequently.

Would much rather “visually” move commits around than accidentally aim “git history” at an orphaned commit hash no longer in my local branch.

WorldMaker11• 8 days ago

The implication seems to be that `git history` is the higher level, safer `git rebase` for common scenarios. If you are already comfortable with `git rebase` you might just keep using it and never need `git history`. If you are learning git as a junior developer (or teaching/mentoring a junior developer on it) `git history` becomes a good, safe stepping stone for a handful of common tasks.

I've been in workplaces where I wished I could disable `git rebase` for all junior developers because they kept learning its footguns faster than its capabilities. A stepping stone seems like a really good idea to me.

skydhash14• 9 days ago

Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.

I think that only happens when you work on code as text files (i.e character streams) instead of code (i.e structured content with meaning). Like you have commit A and commit B that is in conflict, you should be glad because that's a rough signal that the intent of A and B differs. Your goal should be to think about how to compose A and B so that both intent survives (unless one supersedes the other). Which means you should be at least familiar with A and B.

The issue I found with people that fears conflict is that they often don't understand either A or B (or both). So they are a bad candidate to actually do the operation. It's not a matter of git's cli interface, it's a matter of codebase comprehension and how well you're familiar with the changes in question.

thfuran• 9 days ago

Git is the one treating code like a text file instead of code.

UnfitFootprint• 9 days ago

I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter

skydhash14• 9 days ago

Git store whole files. The diff and the merge algorithm works by line by default, but that's because line is a rough unit of code (statement, expression, and definition happens mostly within one line).

bulatb6• 9 days ago

I can fully understand a conflict, know it's coming, and fear it anyway because I'll have to deal with Git's behavior to fix it.

seba_dos112• 9 days ago

Such as?

When you merge a commit in that changed a file that has been already changed since the common ancestor, Git runs a tool of your choice on this file. If the tool fails, it marks the file as needing a merge and doesn't let you commit it until you unmark it to confirm that you have merged it manually. In case of octopus merges, it will just abort early. That's basically its whole behavior when it comes to conflicts.

jolmg12• 9 days ago

scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze

`git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.

catlifeonmars2• 9 days ago

Do you use git reflog?

jolmg12• 9 days ago

One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.

ibizaman• 9 days ago

I do when I forget to run the git branch comment before. But I find it still hard to understand exactly which commit to reset to in the reflog.

rmunn9• 9 days ago

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`.

I've almost never needed to run `get reset before-rebase`. But I have often done `git log -p before-rebase` and compared that to the post-rebase state of the branch, to ensure that the merge-conflict resolution(s) that came up during the rebase haven't accidentally introduced an unintended change.

jolmg12• 9 days ago

but branches can be moved around with less ceremony than tags

`git tag -f` to move a tag.

Personally, I just do `git show` when I'm feeling cautious, but I can generally just scroll up to find the last `git commit` I did with the hash in the output. `git reflog` should also have record of it, so everything else is kind of extra.

chrismorgan• 9 days ago

Diffing diffs is so valuable for that reason, seriously underrated. Once I even found a use case for diffing diff diffs.

I also often wish to edit commits or resolve rebase conflicts or whatever by editing the patch rather than the files.

hack1312• 9 days ago

This is the exact same thing I do, though with the prefix "pre-rebase/"

bjackman• 9 days ago

After a rebase, mybranch@{1} refers to the previous location of mybranch, so you don't need to manually track these before-rebase branches etc.

(In practice I find this syntax super annoying and usually end up typing `git reflog mybranch` and then copy-pasting the commit hash from the output).

WorldMaker11• 8 days ago

git tags are more lightweight than they seem. It's why the UX defaults to not sharing tags, with the idea that you may need/want local-only tags. They also share the same "namespace" that you could have tags like `myname/some-personal-tag`. (I've used `project-name/v1.2.3` style tags in monorepos rather than solitary versioning the entire repo.)

`git tag -d` deletes tags and `git tag -f` moves them (forces them to change).

For the most part whether you prefer a branch or a tag for temporary marks is an aesthetic choice, though the twist is maybe using annotated tags. The annotated tag allows you to leave a commit message for yourself why you made the temporary tag in a way that you can review later. Just like optionally adding a stash message (which also reflects why stashes work under the hood more like tags than like branches).

andrepd• 9 days ago

No need for that even. Just git reflog and rewind back to any spot your want!

dalmo3• 9 days ago

`git rebase --abort` exists

Exactly. 50% of the times I type git rebase it is followed by --abort.

account4211• 9 days ago

You don't even need to set a safety tag like that anywhere in git, the reflog does that for you automatically.

BeetleB3• 8 days ago

jj undo

You can't get simpler than that.

paularmstrong• 9 days ago

`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.

catlifeonmars2• 9 days ago

What does it mean to split a branch in two?

rmunn9• 9 days ago

Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch.

The existing workflow for that would be (there are several possible workflows, but this is what I would do):

  git checkout intermingled-branch
  git branch bugfix-A
  git branch bugfix-B
  git checkout bugfix-A
  git rebase -i
  # Edit the file, keep commits that fix bug A, drop commits that fix bug B
  git push origin bugfix-A:bugfix-A
  git checkout bugfix-B
  git rebase -i
  # Edit the file, keep commits that fix bug B, drop commits that fix bug A
  git push origin bugfix-B:bugfix-B

jolmg12• 9 days ago

Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the changes of the other PR so they should review that one first. Should they want to add changes to the first feature, they just need to checkout that branch, do the changes, and merge to the second feature branch so they're available there.

ellefire• 9 days ago

It's expensive when you factor in each PR having to wait for someone to come and review it - it's easier to get your work done in larger PRs when that's the case, although it's a perverse incentive

CuriouslyC6• 9 days ago

Small stacked PRs are a NIGHTMARE unless your org is consistently turning around PRs in low single digit hours, and team members are working on decoupled code so you don't have any stack weaving. You end up in a situation where the engineering director and some tech leads really like tools like Graphite, while the entire team working under them mutters irately under their breath daily.

hahahaa4• 9 days ago

I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.

what• 9 days ago

You probably shouldn’t be committing things that are broken…

moezd• 9 days ago

With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch. Besides, aren't we all familiar with git commit -m "typo"?

hahahaa4• 9 days ago

Commit yes you absolutely can. Merge to trunk? Probably not, depends on your strategy.

normie3000• 9 days ago

This is likely saying you shouldn't save a word document that contains spelling mistakes.

plorkyeran• 9 days ago

You should be committing things that are broken all the time. Git works great as a persistent navigatible undo buffer, and you should commit every time you're in a state that you might want to return to.

seba_dos112• 9 days ago

Commit graph is just a data structure. Sometimes it represents a "history", sometimes other things.

Personally, I like it when project's repository represents the history of the project rather than the history of random things developers do on their machines, but you do you.

hahahaa4• 9 days ago

I am thinking of remote. Edits before pushing OK with me (they ate equivalent of recloning and redoing anyway)

account4211• 9 days ago

There is history that has already happened (e.g. what has been merged to master) and history that will happen (e.g. unmerged pull requests).

bentt• 9 days ago

Granted, I have a perspective of a game dev, but this kind of repo defiling just gives me the willies. IMO instead of finding a common ancestor and altering it, just make the desired change upstream and merge it to where it’s needed. If you can’t do that then you have already made a deal with the devil and might reconsider your approach. KISS

shepmaster5• 9 days ago

That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch).

I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and update `B` to `B'`:

  A ──► B ──► C ──► D  
        │              
        └───► E

I'll end up with this state, where `E` remains untouched?

  A ──► B' ─► C' ─► D'  
  │                   
  └───► B ──► E

(EDIT: Originally I had `E` point to `B'`, which doesn't make sense)

If I use `git history fixup`, it would also update `E` and end up with this?

  A ──► B' ─► C' ─► D'  
        │              
        └───► E'

If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.

jolmg12• 9 days ago

I'll end up with this state, where `E` remains untouched?

Can't, because a commit's hash takes into account the parent hashes.

Haven't used --update-refs, but reading it, it should result in your third graph. So,

is there a way to get `git rebase` to have the same behavior?

is already the case.

rmunn9• 9 days ago

Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'.

Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.

shepmaster5• 9 days ago

Haven't used --update-refs, but reading it, it should result in your third graph.

I don't think it does. I tried locally:

  mkdir test; cd test; git init
  touch a; git add a; git commit -m 'a'
  touch b; git add b; git commit -m 'b'
  touch c; git add c; git commit -m 'c'
  git checkout -b branched-feature HEAD~
  touch d; git add d; git commit -m 'd'
  git checkout main
  echo 'change' > b; git add b; git commit -m 'fix b'
  git rebase -i --root --update-refs

And ended up with this graph (`git log --graph --all`)

  * commit (HEAD -> main)
  |
  |     c
  |
  * commit 
  |
  |     b
  |
  | * commit (branched-feature)
  | |
  | |     d
  | |
  | * commit
  |/  
  |       b
  |
  * commit 
  
        a

Replacing the `git commit -m 'fix b'; git rebase -i --root --update-refs` with `git history fixup HEAD~` produces what I'd like:

  * commit (branched-feature)
  |
  |     d
  |
  | * commit (HEAD -> main)
  |/
  |       c
  |
  * commit
  |
  |     b
  |
  * commit 
  
        a

seba_dos112• 9 days ago

It won't result in the third graph on its own as E isn't reachable from D, but it could if you first merged D and E together and then used --update-refs with --rebase-merges. You could then just discard the merged branch and only take care of D' and E' on their own (and since you don't care about the merged branch, you don't have to care about resolving conflicts while preparing it either).

lelandfe• 9 days ago

See: https://blog.hot-coffee.dev/en/blog/git_update_refs/

shepmaster5• 9 days ago

I'm not sure that answers my question. That shows a linear set of branches (my-feature-v3 depends on my-feature-v2 depends on my-feature-v1 depends on main). I'm asking about the case where two or more branches fork from a common ancestor and you want to fix the common ancestor.

m4632• 9 days ago

off-topic, but that is a very clear readable comment you left with those line-drawing characters.

shepmaster5• 9 days ago

You can thank ASCIIFlow for that ;)

https://asciiflow.com/

WorldMaker11• 8 days ago

If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.

One of the GitHub blog posts of git changelog highlights implied that this new power of `git history` was certainly under discussion for a possible feature addition to `git rebase` but it is partly still a discussion because it is a higher-level function and if the goal is to keep `git history` the "high level" and `git rebase` the "low level" then such features probably make sense to remain only in `git history` for now.

It also sounds like there are camps thinking `git history` is only the learning path to make a better `git rebase` UX and eventually the commands will reconverge somehow.

Both sides of that conversation sound worth exploring to me, and I'm curious to hear how that conversation continues.

nativeit• 9 days ago

I don’t consider myself a coder or programmer, but learning git was like an organizational superpower for my particular brain wiring. I use it for websites, design projects, electronics engineering, music composition, personal knowledge bases, remote administration scripts, config management, snippets, so many applications and so many features for one system. It’s not always perfect, but I tell everyone I work with they should learn it.

quacked2• 9 days ago

How do you use it for music composition?

knodi123• 9 days ago

there are plenty of text-based digital music notation systems. Then, you commit periodically as your composition evolves, and you can have all the history/fork/undo whatever that you might want.

tunesmith• 9 days ago

I use it for lilypond for notation. I always considered it superior to Finale and Sibelius anyway. Not sure how it stacks up against the more modern commercial notation apps. But I love having a real trackable version history of my pieces.

What's also cool is the more advanced llms know lilypond and music theory too, so they can do things like... I don't know, check for counterpoint errors. I've used it with limited success to expand my jazz lead sheets into two-hand piano arrangements just for practice exercises.

m4632• 9 days ago

I also took a leap in organization. But I don't think you're responding to git in particular, just a source control system.

git (and other version control systems) take what you made, organize and preserve it, and you can get any number of copies at a moment's notice.

It is good for people to be able to do work and not worry about it.

I remember reading David Allen's book Getting Things Done years ago. It takes effort to read through his writing, but he had good ideas.

One thing he mentioned is that you need a 'trusted system' where you can collect and organize your thoughts. It lets you offload what you're worrying about until the time you need to do something with it.

I actually use omnifocus to do this for my tasks/projects/lists, but for what I actually do on a computer, I trust git to organize and preserve the software (and some data) I have written.

_nivlac_• 9 days ago

I like `git history reword`, would've found that useful in the past (e.g. fixing a bad typo in an older commit).

It sounds like there was probably an equivalent using an existing command but this is easier for me to understand. Thanks for sharing!

paxys2• 9 days ago

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

jolmg12• 9 days ago

No one is ever going back and reading individual commits.

Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.

paxys2• 9 days ago

Seeing the individual change in the context of the larger feature is actually more helpful. Otherwise you find a tiny commit that changes A to B and then have to chase down 13 other commits around it to figure out why that change was even made.

seba_dos112• 9 days ago

Of course we do and it helps tremendously when the graph is reasonable.

Myrmornis3• 9 days ago

One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).

assbuttbuttass4• 9 days ago

That sounds like it would break bisect

Cthulhu_5• 9 days ago

That's one approach I suppose, it leaves evidence of "I wrote a test first" and such.

However, it also feels more like a "work log" than a "commit log"; I like to make my commits atomic (test + code at the same time), so that in theory, each individual commit will pass CI. If you separate them, you can't just revert one commit, you need multiple.

broodbucket• 9 days ago

Having a well curated one-logical-change-per-commit history is incredibly valuable when bisecting a regression.

efilife• 9 days ago

Didn't you mean "dissecting"?

Edit: thanks guys, that's very useful knowledge! Could have saved me many times in the past

jhealy• 9 days ago

No one is ever going back and reading individual commits

I do, regularly! In a repository where care has been taken, it can be super valuable when tracking down a bug or regression, and understanding the intent of the author

bad_username2• 9 days ago

The debate between these who don't squash and these who do is the debate between these who use the history for bugfixing and those who don't. And I think not using it is throwing away a super valuable tool that can reduce the fix ETA by an order of magnitude.

jxf• 9 days ago

No one is ever going back and reading individual commits.

I violently disagree with this.

At a minimum, when I review PRs I look at the commit history to understand what's up. If the path that was taken to commit this is full of "oops" and "fix" messages, it's an immediate reject for me. The commits tell the story and it's a kindness to your human reviewers to not make them work harder to understand the point you're trying to get across.

nl• 9 days ago

If the path that was taken to commit this is full of "oops" and "fix" messages

great way to encourage people to rebase then!

bobbylarrybobby• 9 days ago

Do you really care if someone forgot to format before committing? They can always squash and push locally if they need to.

fcarraldo• 9 days ago

Mine aren’t full of “oops” and “fix” messages, because I squashed them.

GrandfatherTECH• 9 days ago

What's up with the fix commits? Maybe I misunderstood you, but there ain't nothing wrong in fixing stuff you offer in your PR. And there can also be multiple commits even before the PR while you're developing your PR.

danieltanfh95• 9 days ago

NGL AI usage is driven by friction in presentation and communication over petty details.

InvertedRhodium• 9 days ago

Depends what the git history is supposed to show. Personally, I prefer people to leave their mistakes and reversions - though I'd require more description messages than "oops" or "fix", something that explained why it was being reverted or swapped out would be the minimum.

Sometimes you try things one way and they don't work out, so you go in a different direction. Capturing why this happened and when can go a long way towards explaining downstream decisions that might seem confusing to someone with a fresh perspective.

gofreddygo• 9 days ago

Oh that is such a bad heuristic ! The commits and history of how a PR was put together is no indicator of the quality of the PR or the thought process that led to it. Thats the equivalent of rejecting a (handwritten) essay for having too many corrections. ridiculous.

The code is all that should matter. Maybe comments for being nice to others and my future self. thats it.

JohnMakin• 9 days ago

yea I look at commits several times a week at least, especially when commits are tied to a ticketing system/project it helps a lot going back months later on a large codebase going “how/why did this change happen”

I do tend to squash or make my entire change in one commit though so maybe I misunderstood your comment. If I have a fix commit often I’ll just tag a separate PR/ticket to keep the change history/change control clean

ozim3• 9 days ago

But parent wrote:

Just squash everything before merging and call it a day.

He didn’t write „leave a mess”. So it feels you wrote knee jerk comment or just writing whatever you wanted to write disregarding whatever was written.

ansgar77• 9 days ago

I think that the path that was taken should include mistakes. It's natural that code at some point would contain bugs and mistakes. If anything, your approach would encourage to squash those commits into one just to make it being review-worthy, but that misses the point then.

CuriouslyC6• 9 days ago

You sound pleasant to work with. I bet your coworkers route around you when they can, and when they can't they cherry pick from their working branch to deliver monolithic commits while rolling their eyes.

crabbone2• 9 days ago

Parent doesn't have experience of working with codebases with slightly high than average code quality requirements.

In products s.a. storage, avionics, medical appliances etc. it's very typical to have a requirement for each commit to compile and to apply tests retroactively. I.e. once a test is added against an existing feature, it is run against every commit since the feature creation (this is also why git-bisect exists).

However, it's true that a lot of companies would probably do better with just rsync instead of Git. Their Git history is in such a bad state that it's basically useless. It just doesn't make sense to use such a complicated tool as Git to deal with the average workflow.

EPWN3D• 9 days ago

Sorry, no. Just because you've never done it doesn't mean that no one ever will.

Beyond the archival benefits, I've found plenty of bugs by going back through my "wip" commits and creating a sane history from them.

vcf• 9 days ago

I almost never went back to read the history, but now I often have Claude go through the history when I wonder how we got to a certain point. It can point me to the relevant issues as well. Squashing is fine, up to a point.

ex1fm3ta• 9 days ago

I do not agree at all. When you have multiple repos accross different services, commits are the best way to follow up with differents changes. We adopted conventional commits guidelines a few months ago and everyone is happy. Even ClaudeCode is able to keep up and auto fix stuffs with the proper commit messages. The changelog is dynamically updated. Everything so smooth when those commits messages are perfectly synchronized.

sitkack• 9 days ago

That is like saying once the program is done, throw away the source.

Lemme guess all your for commit say "wip"

yjftsjthsd-h• 9 days ago

It's really not. Source code, even with no history, can be modified, adapted, ported, fixed, and improved. Having history is nice, but it's way lower marginal utility.

msteffen• 9 days ago

One use-case for curating commits other than git history is carefully structuring code reviews to be easy to review. Eg "commit 1 just rearranges existing code, no business logic changes"..."change 2 modifies business logic, but in one localized place as the refactoring has already been done"..."change 3 only modifies comments"

locknitpicker12• 9 days ago

No one is ever going back and reading individual commits.

Your assumption doesn't match the real world practices I've experienced for years across multiple jobs. Even at the PR stage a clean commit history is of critical importance. Nowadays, with ai coding assistants assuming a central role in developing software, commit history is even used as input with context signal, allowing for flows such as "evaluate the changes in commit X and Y and apply the same pattern to project Z".

Just because you don't use a tool properly that doesn't mean everyone around you makes the same mistake.

Izkata2• 9 days ago

I do multiple times a week, with repos that have barely been touched in a decade and all the original devs are gone. Squashing would make figuring out why something is the way it is a lot more painful, so I'm glad these repos are svn where squashing wasn't an option. Several times I've discovered bugs that were introduced in linting commits that would have been squashed, so the fix ends up trivial since the intention is already there in the previous commit.

smcameron4• 9 days ago

Disagree. You need small, git bisectable commits. Use stgit to do it and it's nearly effortless.

nextlevelwizard• 9 days ago

How do I know you don’t work in a big team from this?

First thing I do every time I come back from vacation is to read through our git history to see what has happened.

It is also very useful when CI breaks. In fact I probably use some form of git history reading every day at work.

Also if your code base is so tiny and the features you work on are so small that you can just squash everything then maybe that is fine for you. I definitely love being able to actually see what is going on and selectively cherry picking or reverting commits

fragmede2• 9 days ago

No one is ever going back and reading individual commits.

Hell yes we are! Just because you aren't going to doesn't mean nobody else is going to.

LtWorf6• 9 days ago

Spoken like a guy who really really doesn't understand how git works and has never bothered to learn!

penguin_booze• 9 days ago

Might as well go back to the tar.gz days, eh?

aardvark179• 9 days ago

Having maintained internal forks, and having needed to pull in and rebase upstream changes I do read a lot of commits. Projects that take care with their commits are much easier to work with.

This is also true when creating with security patches and other things that need to be backported to multiple releases.

dkdbejwi383• 9 days ago

I could count the number of times I've written a detailed summary in the body of a commit message, and had it read by my colleague reviewing who then didn't need to leave a comment on the PR asking why I did _x_ on zero hands.

Cthulhu_5• 9 days ago

I have a more nuanced view of this; in libraries and software projects that span years like Linux, curl, etc, this happens all the time. Bugs get fixed and they can point to the exact commit where it was first introduced, and that commit contains all information necessary to figure out why it was introduced in the first time.

But that's projects like Linux, which is a whole different use case than for example what I do for a living, front-end applications that have at best a lifespan of 10 years and whose individual features / screens / components have less than that, and it's much more rare that an older commit is still relevant today.

(that said, looking history up has made me dislike squash commits. I get it from a pragmatic point of view but it's not ideal)

Hendrikto3• 9 days ago

I am always aghast at how proudly people pronounce that they don’t know how to use one of the most central and essential tools in the belt of a software engineer.

Maintaining history is well worth it, and allows you to use tools like

    git rebase
    git revert
    git bisect
    git blame
    # …

It also makes reviewing and understand your code much easier.

fragmede2• 9 days ago

git bisect, connected to a script that outputs good/bad, is one of computing's crowning achievements, imo.

CuriouslyC6• 9 days ago

Squashing everything has a significant downside compared to functional atomic commits: git-bisect gets WAY less useful.

christophilus• 9 days ago

I’m with you, but it’s obviously a sensitive topic for a lot of folks, based on the replies. Some people’s brains are just wired differently, I guess. I rarely look at history, other than git blame. For me, history does not need to be granular at all. The replies make it sound like curating git history is the job, rather than shipping solutions to customers’ problems. I guess, if it helps you ship faster / better, more power to you.

jcon321• 8 days ago

yea i agree, the people who defend perfect git history are most likely not enforcing pull/merge requests. why would I care to look at git history when a pull/merge request is way more informative? they then back it up by saying how rebase is so much better than merge, but yet when you git blame a line of code that was merged and not rebased it's going to indicate the pull/merge request which is going to link back to a requirement. sorry for the harsh comments from these people about you, because imo perfected git history is actually the lazy approach instead of proper change/requirement management

chandlerswift• 9 days ago

I've been theoretically a big fan of these commands; I use the `jj` equivalents all the time. The roadblock I've run into is that I as far as I can tell (from the man pages and the git source code) there's no way to get `git history` commands to sign commits they modify:

    $ git log --oneline --show-signature  # look ma, I signed my commits!
    3a1dd8f gpg: Signature made Mon 13 Jul 2026 10:45:50 PM CDT
    gpg:                using RSA key FBF32CDBCC134B44FD29B66FA851D929D52FB93F
    gpg:                issuer "chandler@chandlerswift.com"
    gpg: Good signature from "Chandler Swift <chandler@chandlerswift.com>" [ultimate]
    Second commit
    03c3f6e gpg: Signature made Mon 13 Jul 2026 10:45:16 PM CDT
    gpg:                using RSA key FBF32CDBCC134B44FD29B66FA851D929D52FB93F
    gpg:                issuer "chandler@chandlerswift.com"
    gpg: Good signature from "Chandler Swift <chandler@chandlerswift.com>" [ultimate]
    Initial commit
    $ git history reword HEAD~
    $ git log --oneline --show-signature  # oops! where'd they go?
    5662b2c (HEAD -> main) Second commit
    6bf6830 Initial commit amended

This has pushed me back to the time-honored `git rebase -i` since I do want to keep my commits signed.

jmholla2• 9 days ago

Woah! That feels like a huge oversight and like it bypasses standard commit logic. The man pages do say `git history` is experimental. Sounds worth a bug report.

smcameron4• 9 days ago

Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.

I mean, just use stgit[1] to maintain a stack of patches instead of parallel branches, it's so much better. You can easily wrangle thousands of patches (aka commits) with stgit.

A lot of people, on first encountering stgit, read a bit about it, think "why do I need this? I can do the same thing with just plain ol' git.". Yeah, you can. But not at scale. Not practically. Not with thousands of commits. And it makes the case when you just have a few tens of commits absolutely trivial. Try it for awhile and you'll find it indispensible.

[1] https://stacked-git.github.io/

froh2• 9 days ago

TIL, thx :-)

somewhat related Q:

how do you give two files the same ancestor? so git log will for each show the history to the beginnings of the originally unsplit file? useful for splitting large files.

bonzini7• 9 days ago

That's not possible, because files don't have ancestors in git. Each commit's tree is tracked independently and copy/move is just something that's detected via heuristics.

account4211• 9 days ago

But those heuristics could be better than they are now so that a git log <file> will show the shared history for both copies.

froh2• 1 day ago

I meanwhile understood that you can commit a copy of a file and then edit both, and then the ancestry tracking options to git log resolve the two split parts ancestry just fine.

krick• 9 days ago

scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze

Complete bullshit. Might as well say "scary screwdriver that can turn up in your recturm if you so much as sneeze". Sure, I believe that might have happened to you (heard stories from friends that work in the emergency room), but I run rebase -i 10 times during the time I work on each branch (literally: I don't even care to write "proper" commit messages while writing the code, will reorganize and clean them up later anyway), and it never happened to me.

eviks2• 9 days ago

commit messages while writing the code, will reorganize and clean them up later anyway

That's just too primitive of a workflow, so repeating it will not run into the risk. You need to add an actual conflict in some feature branch and get stuck being forced to resolve it to compete the rebase to appreciate the op warning

rushil_b_patel• 9 days ago

the "reword" option is same as git rebase -i HEAD~n, and then instead of pick replace it with reword to change the commit messsage.

BTW I have made a notion doc on git commands: https://rushilpatel.notion.site/git

eviks2• 9 days ago

Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.1

That's not really trying, let's assume you need 1 week to change ingrained workflows, so you just waste time every 3 months stopping right before the threshold. Better try once every year, but for a few*4 days...

kazinator4• 9 days ago

The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as:

   This regression was caused in <hash> on December 19, 2017.

The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit.

I have scripted this before!

inigyou9• 8 days ago

Don't change old commits. Change commits you haven't pushed yet.

kazinator4• 8 days ago

That's not for you to dictate to someone about some project you have no idea about.

Git is not a religion or cult.

Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.

kazinator4• 8 days ago

By the way, the proper job of doing this recognizes abbreviated hashes also and fixes them up to equally abbreviated hashes.

bad_username2• 9 days ago

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

xyzsparetimexyz2• 9 days ago

No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.

palata2• 9 days ago

So when someone tells you "understanding X helped me a lot", your answer is "no, it did not"?

It's not 1:1 at all.

I don't see any mention of "1:1" in the parent.

hnfong• 9 days ago

Same here. The git commands were confusing to me until I actually saw a Linus video on youtube explaining how the git data structures worked under the hood. It was dead simple, and one could easily mentally map the tools' functions onto how they operated on the data structures.

Once I understood that, as you said, everything clicked into place.

Somehow the "higher level abstractions" that git tries to do makes the things ever so more confusing.

rmunn9• 8 days ago

I've recommended https://learngitbranching.js.org/ to so many people. Something about seeing it visually, with the arrows pointing from child to parent, just clicks in the mind where a written explanation doesn't. (Not for everyone, of course: some people understand it quite well from the written explanation. But if your coworkers who don't grok Git are visual learners, https://learngitbranching.js.org/ might be the thing that helps them unlock a deeper understanding of what's going on with branches and HEAD and so on).

psychoslave3• 8 days ago

Can you point to this video please?

thr0w__4w4y• 4 days ago

Not Linus, this is Randal Schwartz, but this might be the video you're thinking of?

https://www.youtube.com/watch?v=8dhZ9BXQgc4

vasco• 9 days ago

Mercurial had by far the best UX, never had to read anything to learn it. I just pretend that I'm using mercurial when using git and nuke local repo if I mess up. Been doing it for my whole career.

black_knight• 9 days ago

I love darcs! Somehow its interface just vibes with me. It is interactive by default, and the commands like “record”, “rollback”, etc, are somehow intuitive. Darcs also tried to put more semantic content in the patches, like file operations or search replace parches.

It is always satisfying to rename something, then merge in some work where someone used the old variable name in the meanwhile, and the merge would go through automatically applying the rename!

yurishimo• 9 days ago

I've often found that many problems when working in teams can be traced back to `rebase`. I understand the benefits, but if you're already working on a team where history is not used in any serious way, then you cut out a lot of foot-guns by only using `merge`.

BeetleB3• 8 days ago

I loved Mercurial, but once I learned jj, I never looked back.

Hendrikto3• 9 days ago

Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer.

    git commit -am “Changes”

just does not cut it, if you call yourself a professional.

hackrmn4• 9 days ago

My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentially immutable), they don't venture farther than their confidence suggests, keeping it within the circle so to speak.

The tragedy, if you ask me at least, is rather that they then start imposing the "keep it simple" culture onto everyone else, which frankly turns Git into what SVN and CVS were accomplishing before it, with all the drawbacks of those. This keeps 90% of the team satisfied 90% of the time because there's nothing wrong with strictly linear graphs and the pro's that are asked to produce these, can always squash-merge their intricate local development history before they push to Github (which some Git users also think is part of Git proper).

Something about using Git in the aforementioned way just bugs me strongly. I admit it's a me problem, very likely, but lately I've also had to admit that it's not just that either.

For instance, if I need to fix a bug I use `git blame` to find the commit where I have learned the bug originated. I do a `git checkout -b ... <commit>` to start working on a fix, creating a branch starting at the problematic commit. Already that is head and shoulders above what many people I work with do or know _what_ does (or why would one want to do that).

I do it because it creates a _trail_, certainly more so than just committing on top of `master`, even with a good commit message.

But my practice doesn't produce linear graphs, even as pushed to Github (which we have to use, for better and for worse) and shared with everyone. I then get people coming to me and complaining they can't merge and it becomes obvious they don't understand Git sufficiently to do anything else but `git reset --hard` or worse, `rm -rf * && git pull` and hope for the best.

Not sure where I was going with this, something about why use Git when it's the new SVN with everything SVN had and none of what SVN didn't have...

kreco7• 9 days ago

Git is not nearly as confusing as people make it out to be.

The people are confused, it's a fact. So it is confusing. Stop gaslighting people.

jchook• 9 days ago

Obligatory git joke.

Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space

https://softwareengineering.stackexchange.com/questions/2564...

mlrtime2• 8 days ago

As he sits on his thrown looking down on others.

If what you said was true, https://ohshitgit.com/ wouldn't exist.

Someone• 8 days ago

The UI of git - for better or worse - directly reflects its internals.

I disagree. For example, we have, from “git checkout —help”:

   git checkout has two main modes:

   1. Switch branches, with git checkout <branch>

   2. Restore a different version of a file

The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals?

(And of course, there are many inconsistencies in the CLI that do not have to do with git internals that, even if you know what you want to do internally and which command to use, make figuring out the CLI incantation to do it harder than needed. That’s a different subject, but still contributes to “git is difficult to use”)

inigyou9• 8 days ago

I think they tried to fix this by adding new separate commands, right? git restore?

dundarious2• 8 days ago

Switching branches involves: updating the field marking "current branch", and then updating the working copy to reflect the objects referenced. So for all trees/files, recursively restore wc to match the referenced blobs.

Restoring a different version of a specific file/tree, involves recursively restoring wc of those files/trees to match the referenced blobs.

So both are actually primarily the same task. Knowing a little about internals is exactly how it is easy to understand how the same code (and hence the verb "checkout") came to be used for both tasks.

The reason it's still not great UI is that switching branch and restoring file arise in very different circumstances, and I want different guarantees and warnings and confirmations -- so using the same command still only makes sense when thinking very mechanistically.

runtime_lens• 9 days ago

git reflog is probably the Git command that has saved me the most stress. At some point you stop worrying about experimenting because you realize it's surprisingly hard to lose work permanently. Git is muuch more forgiving than it first appears.

xyzsparetimexyz2• 9 days ago

Tldr; use jj

SCUSKU• 9 days ago

These graphics are great. Makes for a skimmable high signal article, nice work!

jonathanlydall• 9 days ago

I've been doing regular significant re-writes to my local Git commit history with relative ease for over a decade even without this new Git command.

I'm convinced that a big part of people often finding Git and rebase difficult is a user interface issue, having to know all the correct command line options and having to make your own mental model of what's happening and what you want to do, all makes it difficult to get a firm grasp on things.

I can't comment on what equivalent alternatives (especially on macOS/Linux as I'm a Windows user), but in terms of a UI for Git which exposes enormous power in an easy-to-use way I've found TortoiseGit to be spectacular and I especially like its rebase dialog:

https://tortoisegit.org/docs/tortoisegit/tgit-dug-rebase.htm...

Which you kick off from a context menu option from the commit line on the commit log you want to rebase onto with a simply named "Rebase <current reference> onto this" option:

https://tortoisegit.org/docs/tortoisegit/tgit-dug-showlog.ht...

It's super easy to re-order, split, combine, edit commits from here and it's obvious that will happen. If for whatever reason you decide you want to back out midway, you just abort and you're back to where you were.

I will concede there are aspects of a TortoiseGit I find a bit annoying, particularly that I feel I have to click around too much, instead of a shell extension I would prefer an app you launch with tabs or something, but I think this is a fundamental design principle of TortoiseGit, which followed the same principle as TortoiseSVN.

There is Git Extensions for Windows which seems nice at a glance, I tried it briefly, but I think I didn't stick with it either due to being unable to find an option I regularly used or I was just so used to TortoiseGit already.

Cthulhu_5• 9 days ago

Same, but at the same time the existing workflow is a bit more clumsy / these commands are a bit more ergonomic.

Fixup was already possible through `git commit --fixup`, and before that through `git rebase -i`; reword also through `git rebase -i`. I suppose the developers got enough feedback that editing a file to decide what to do with each commit was a bit frustrating for some users.

It's a higher level command on existing functionality I suppose.

crabbone2• 9 days ago

In terms of UI for Git, I've never seen anything getting remotely close to Magit. It's both in-depth and a simplified stateful interface.

Here's what I mean by "stateful": one of the huge problems with command-line tools is that their output becomes mostly inaccessible upon subsequent invocations. Suppose you ran git-log, and now you want to apply the knowledge gained from reading its output to your next action (say, you want to cherry-pick a commit). But you are lucky if the hash of the commit in question is still somewhere in the terminal. Otherwise... you aren't writing that from memory...

Stateful UI to command-line tools allows multiple interactions in parallel and preservation of information obtained in previous interactions.

Git needs a lot of state. You need to remember facts s.a. what branch you are on, what branch did you switch from, what files have been modified, what commits haven't been pushed etc. The requirement to remember all of this is overwhelming and makes the effective use of the tool difficult. This is where various tools come to help (eg. Shell plug-ins that provide auto-completion or modify the prompt to incorporate some of that state info).

I believe that people complaining about difficulties of using Git are often handicapped in their use of surrounding tools that would otherwise mitigate the problems above: they don't know how to add Shell plug-ins that display the current branch, they don't know how to have multiple tabs/panes open in a single terminal session, how to copy text between those tabs/panes, they don't know how to invoke / search auto-complete options.

Genuinely, if you don't have tools to help you use Git, something that people who are used to navigating the world of terminal UI, using Git becomes very unpleasant.

inigyou9• 8 days ago

As a former Windows user now on Linux, one of the things I miss is the single unified shell, where every installed program could install new right-click options on files and folders, overlay icons (like TortoiseGit's VC status icons), special objects that aren't files or folders (like My Computer), and so on. I understand this peaked in XP and from Vista onwards Microsoft started changing the shell in less-extendible says.

(but I'm still really confused why VC++6 had some menu option that would create a folder-like shell object and open it in a file-open dialog instead of just using a listview like everyone else. It was some kind of "add component to project" wizard, and I'd always try to find that fake folder in My Computer while the dialog was open)

WorldMaker11• 8 days ago

One interesting new twist in the Windows 11 removes extension points/makes extension points harder to use is first class built-in git version control integration: https://learn.microsoft.com/en-us/windows/advanced-settings/...

It is not as convenient and it is not yet as capable as things like Tortoise have been in the past, but it is still an interesting thing to see paths explored in Windows like that, even if somewhat hidden in "Advanced Settings".

Sharlin• 9 days ago

Huh, TIL about `git commit —fixup`.

Cthulhu_5• 9 days ago

Yeah I learned that one a few months ago, before that I'd use interactive rebase and shuffle the commits around manually in the editor that opens.

I appreciate that these commands are just utilities / conveniences on top of a stable base though.

rom1v• 9 days ago

`git history fixup` fixes an old commit that has something wrong in it, then autorebases all your branches to match.

Simplifying `git rebase -i` is a great idea, but unfortunately, that does not match my workflow.

I always keep an history of my branches. For example, when I develop a feature, the first version of the branch is `myfeature.1`, then `myfeature.2`, and so on. This is useful because I can retrieve an old version when something behaves differently in a newer one. (And no, `git reflog` will not help)

This has saved me multiple times. For example, I can determine that a problem was introduced between `myfeature.58` and `myfeature.59`. If the "feature" contains 15 commits, I do:

    git range-diff myfeature.58~15..myfeature.58 myfeature.59~15..myfeature.59

This lets me see the changes between the 2 versions, commit by commit (even if they don't have the same base).

I don't want all the branches containing a commit to be rebased automatically (I already try using tags for old versions instead, but this does not quite fit).

anuramat• 9 days ago

is there a way to use it with lazygit? unfortunately I'm addicted atp, and "autorebase branches" is exactly what I was missing the entire time

niels_bom• 8 days ago

lazygit can already reword

quibono2• 9 days ago

scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze

I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around...

Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day.

Also: does anyone know if `magit` has history support?

seanc• 8 days ago

Not as such, but out of the box you get reword and fixup as first-class rebase macros. I use them all the time.

If you wanted to split a commit you'd still have to use a magit-assisted rebase.

So if magit added explicit 'history' support I just about wouldn't notice, it would mostly be under the hood.

quibono2• 8 days ago

100% agree, the fixup macro is amazing. It even fails gracefully when unable to commit for whatever reason.

The split one would be handy though.

whilenot-dev• 9 days ago

Cool, didn't know about `history fixup`! I only ever did the manual dance with `rebase -i` and `rebase` for all other branches. That and `history split` will sure come handy!

What happens with a conflicting fix though? Do I still need to resolve all conflicts on the base branch and `reset --hard` all other branches?

klibertp4• 8 days ago

IME, the only real pain point with JJ is Git integration. I love it, it's great in almost everything it does. Formalizing all the DSLs and using them consistently throughout the config and CLI is exactly how filesets, revsets, and templating should be implemented. The focus on exposing concepts as interfaces (without "directly reflecting internals"[1] in the UI) is only as good as the concepts themselves, and in JJ's case, they are powerful. The problem is that they are too flexible, so Git interop relies heavily on convention and discipline... which is fatal. The fact that (almost?) all states of JJ are representable in Git makes it easy to mess up your remote, and then you need a very solid understanding of Git to fix it.

If you can give `jj` a try on a greenfield, single-developer project, you probably should. It feels exactly like Git felt compared to Subversion (when you focus on JJ's strengths and use it in favorable conditions - it is young, after all). Get acquainted with `jj` on its terms, and if things click for you, you'll be a bit better prepared for the bumpy road that is Git interop later on.

[1] https://news.ycombinator.com/item?id=48903054

steeleduncan• 8 days ago

In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now.

I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM.

If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more.

klibertp4• 8 days ago

The backend itself is fine, it's just trying to use JJ as a Git frontend for projects developed on Github (among 20 other devs using git, where each of them uses git through different interface and/or in different style) that's currently not ideal :(

However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM.

Yeah, but I think that's fine. Git is a solid foundation; it's not wrong to try to build on it initially. It gets you a usable implementation faster. It is a pain point, though.

If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more.

Is that a danger? I don't see Git as a fast-moving target. And among all the "convenient wrappers on top of Git", JJ seems to have the design least tied to Git, so I think it has the highest chance of breaking out of the Git dependency in the future.

warmwaffles• 8 days ago

All I want to do is reword and correct commit messages / improve them without rebasing everything. When working with teams this is a sure fire way to create absolute chaos.

The git history command

Related Stories