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

61–70 of 330 posts

Re: The git history command

#61

Post by jxf »

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're trying to get across.

Re: The git history command

#62

Post by EPWN3D »

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.

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.

Re: The git history command

#63

Post by jolmg »

efilife wrote: post #60
broodbucket wrote: post #51

Earlier quoted context omitted.

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

Didn't you mean "dissecting"? Edit: thanks guys, that's very useful knowledge! Could have saved me many times in the past

  man git-bisect

Re: The git history command

#64

Post by seba_dos1 »

efilife wrote: post #60
broodbucket wrote: post #51

Earlier quoted context omitted.

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

Didn't you mean "dissecting"? Edit: thanks guys, that's very useful knowledge! Could have saved me many times in the past

Check out "man git-bisect".

Re: The git history command

#65

Post by nl »

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…

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

great way to encourage people to rebase then!

Re: The git history command

#66

Post by psadauskas »

efilife wrote: post #60
broodbucket wrote: post #51

Earlier quoted context omitted.

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

Didn't you mean "dissecting"? Edit: thanks guys, that's very useful knowledge! Could have saved me many times in the past

Nope, `bisect`: https://git-scm.com/docs/git-bisect

Figure out a command to test it, a known-good sha and a known-bad sha, and it will binary search its way through the history to find the commit that introduced the failure.

Re: The git history command

#67

Post by bulatb »

seba_dos1 wrote: post #45
bulatb wrote: post #44

Earlier quoted context omitted.

I understand how rebase works and use it many times a day. Thanks for trying to explain but I won't respond further.

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 going to happen.

bulatb: I do. The process is unpleasant.

seba_dos1: You must not understand what's going to happen.

Re: The git history command

#68

Post by bobbylarrybobby »

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…

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

Re: The git history command

#69

Post by vcf »

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

Re: The git history command

#70

Post by fcarraldo »

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…

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