Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The git history command

lalitm.com

Post reply on HN
Print view View original

71–80 of 330 posts

Re: The git history command

#71

Post by shepmaster »

m463 wrote: post #58
shepmaster wrote: post #16

> 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 upda…

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

You can thank ASCIIFlow for that ;)

https://asciiflow.com/

Re: The git history command

#72

Post by GrandfatherTECH »

jxf wrote: post #61
paxys wrote: post #43

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.

> 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'r…

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.

Re: The git history command

#73

Post by Myrmornis »

assbuttbuttass wrote: post #56
Myrmornis wrote: post #49

Earlier quoted context omitted.

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).

That sounds like it would break bisect

Fair. I think what I'd say is that we don't have to use plain git bisect -- it would be quick to make a bisect script that doesn't land on the failing-test commits. Especially seeing as most teams squash before merging, we should have the freedom to create failing-test commits.

Re: The git history command

#74

Post by ex1fm3ta »

paxys wrote: post #43

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.

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.

Re: The git history command

#75

Post by seba_dos1 »

bulatb wrote: post #67
seba_dos1 wrote: post #45

Earlier quoted context omitted.

These aren't troubles of someone who understands. If anyone else reading this has these kinds of troubles too - don't worry, understanding abstractions takes time and effort, you'll get there eventually (not if you'll keep blaming others though).

Let me eat the crow of getting drawn back in and cap this conversation with a summary. I think this is important because criticizing Git's UX is always like this. OP: No one should be worried about using Git to do a thing. bulatb: I'm worried it will be unpleasant. seba_dos1: Here is what will happen when you do the thing. bulatb: I know, but doing it will be unpleasant. seba_dos1: You must not understand what's goin…

Had you actually read what I wrote, you would rather summarize it as "Git is showing exactly what's going to happen when you attempt to do it, all you have to do to make is pleasant is to not ignore it". Reading things requires unpleasant effort though, I get it.

Re: The git history command

#76

Post by danieltanfh95 »

jxf wrote: post #61
paxys wrote: post #43

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.

> 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'r…

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

Re: The git history command

#77

Post by chandlerswift »

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 " [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 " [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.

Re: The git history command

#78

Post by InvertedRhodium »

jxf wrote: post #61
paxys wrote: post #43

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.

> 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'r…

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.

Re: The git history command

#79

Post by [deleted] »

seba_dos1 wrote: post #75
bulatb wrote: post #67

Earlier quoted context omitted.

Let me eat the crow of getting drawn back in and cap this conversation with a summary. I think this is important because criticizing Git's UX is always like this. OP: No one should be worried about using Git to do a thing. bulatb: I'm worried it will be unpleasant. seba_dos1: Here is what will happen when you do the thing. bulatb: I know, but doing it will be unpleasant. seba_dos1: You must not understand what's goin…

Had you actually read what I wrote, you would rather summarize it as "Git is showing exactly what's going to happen when you attempt to do it, all you have to do to make is pleasant is to not ignore it". Reading things requires unpleasant effort though, I get it.

[deleted]
Post reply on HN