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

121–130 of 330 posts

Re: The git history command

#121

Post by ozim »

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…

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.

Re: The git history command

#122

Post by eviks »

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

Re: The git history command

#123

Post by ozim »

bonzini wrote: post #110
fcarraldo wrote: post #70

Earlier quoted context omitted.

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

So you're "spending effort in perfectly curating git history" and agreeing with your parent comment.

Just squash everything before merging and call it a day

That is also a line from top comment. Everyone read „perfectly curating git history” and went rage commenting instead of reading and understanding what OP wrote.

Re: The git history command

#124

Post by NateEag »

gbalduzzi wrote: post #112
locknitpicker wrote: post #88

Earlier quoted context omitted.

> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…

> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches

I once root-caused a revenue-losing bug that had the entire rest of my team stumped with ten minutes of git-bisect.

It only worked that well because the team had all internalized my advice to write small, coherent commits, so the bisect landed on a ten-line change.

I strongly dislike the recent trend towards squashing every branch into a single monster commit.

Re: The git history command

#125

Post by kazinator »

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

Re: The git history command

#126

Post by LtWorf »

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.

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

Re: The git history command

#127

Post by LtWorf »

NateEag wrote: post #124
gbalduzzi wrote: post #112

Earlier quoted context omitted.

> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches

I once root-caused a revenue-losing bug that had the entire rest of my team stumped with ten minutes of git-bisect. It only worked that well because the team had all internalized my advice to write small, coherent commits, so the bisect landed on a ten-line change. I strongly dislike the recent trend towards squashing every branch into a single monster commit.

Most people who squash things have never used git bisect, cannot solve a merge conflict and when there is one will just delete the directory and clone everything again. I've worked with such people. They can go on like this for an entire lifetime.

Re: The git history command

#128

Post by LtWorf »

bobbylarrybobby wrote: post #68
jxf wrote: post #61

Earlier quoted context omitted.

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

I really really really do not want the autoformatter stuff happening in the same commit as where the real thing happens. I don't care to review if the autoformatter is working properly.

Re: The git history command

#129

Post by bad_username »

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.
Post reply on HN