7 ms·

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 befo

by paxys 4mo 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.

jolmg 4mo 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.
- paxys 4mo 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.
  - jolmg 4mo ago
    Yeah, there's a balance. I try to make my commits so they make sense on their own. > commits around it to figure out why that change was even made. A commit should be such that the message can articulate the why.
seba_dos1 4mo ago
Of course we do and it helps tremendously when the graph is reasonable.
Myrmornis 4mo 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).
- assbuttbuttass 4mo ago
  That sounds like it would break bisect
  - jolmg 4mo ago
    Right, maybe a better way to get what they're going for would be git checkout @~ ^tests where ^tests is zsh's way of saying * except for tests. So you get the tests/ of the current commit and the code of the prior.
  - Myrmornis 4mo ago
    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.
  - locknitpicker 4mo ago
    > That sounds like it would break bisect Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a test at all.
    - account42 4mo ago
      And you can also use bisect by first figuring out the broken commit some other way and then marking everything as good if its before that one or bad if its after - but that's not a very productive use of bisect and if its the only available one I think its fair to call it broken.
      - locknitpicker 4mo ago
        > And you can also use bisect by first figuring out the broken commit some other way (...) Bisect exists to be a tool you can use to fix the problems you are facing. It you are faced by problems you create for yourself and you are unwilling to work around the problems you are creating then there is no tool on earth that can help you.
broodbucket 4mo ago
Having a well curated one-logical-change-per-commit history is incredibly valuable when bisecting a regression.
- efilife 4mo ago
  Didn't you mean "dissecting"? Edit: thanks guys, that's very useful knowledge! Could have saved me many times in the past
  - jolmg 4mo ago
    man git-bisect
  - seba_dos1 4mo ago
    Check out "man git-bisect".
  - psadauskas 4mo ago
    Nope, `bisect`: https://git-scm.com/docs/git-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.
jhealy 4mo 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_username 4mo 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.
EPWN3D 4mo 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.
jxf 4mo 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 4mo 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 4mo ago
  Do you really care if someone forgot to format before committing? They can always squash and push locally if they need to.
  - locknitpicker 4mo ago
    > Do you really care if someone forgot to format before committing? Not OP but yes I definitely do. If you expect others to spend time reviewing your code, you are obligated to start off by reviewing it yourself. Posting a mess helps no one and makes code harder to audit.
  - LtWorf 4mo ago
    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.
- fcarraldo 4mo ago
  Mine aren’t full of “oops” and “fix” messages, because I squashed them.
  - bonzini 4mo ago
vcf 4mo 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 4mo 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 4mo ago
That is like saying once the program is done, throw away the source. Lemme guess all your for commit say "wip"
- yjftsjthsd-h 4mo 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 4mo 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"
locknitpicker 4mo 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.
Izkata 4mo 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.
smcameron 4mo ago
Disagree. You need small, git bisectable commits. Use stgit to do it and it's nearly effortless.
nextlevelwizard 4mo 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
fragmede 4mo 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.
LtWorf 4mo ago
Spoken like a guy who really really doesn't understand how git works and has never bothered to learn!
penguin_booze 4mo ago
Might as well go back to the tar.gz days, eh?
aardvark179 4mo 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 4mo 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_ 4mo 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)
Hendrikto 4mo 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.
- fragmede 4mo ago
  git bisect, connected to a script that outputs good/bad, is one of computing's crowning achievements, imo.
CuriouslyC 4mo ago
Squashing everything has a significant downside compared to functional atomic commits: git-bisect gets WAY less useful.
christophilus 4mo 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 4mo 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

by paxys 4mo 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.

jolmg 4mo 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.

paxys 4mo 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.
- jolmg 4mo ago
  Yeah, there's a balance. I try to make my commits so they make sense on their own. > commits around it to figure out why that change was even made. A commit should be such that the message can articulate the why.

seba_dos1 4mo ago

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

Myrmornis 4mo 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).

assbuttbuttass 4mo ago
That sounds like it would break bisect
- jolmg 4mo ago
  Right, maybe a better way to get what they're going for would be git checkout @~ ^tests where ^tests is zsh's way of saying * except for tests. So you get the tests/ of the current commit and the code of the prior.
- Myrmornis 4mo ago
  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.
- locknitpicker 4mo ago
  > That sounds like it would break bisect Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a test at all.
  - account42 4mo ago
    And you can also use bisect by first figuring out the broken commit some other way and then marking everything as good if its before that one or bad if its after - but that's not a very productive use of bisect and if its the only available one I think its fair to call it broken.
    - locknitpicker 4mo ago
      > And you can also use bisect by first figuring out the broken commit some other way (...) Bisect exists to be a tool you can use to fix the problems you are facing. It you are faced by problems you create for yourself and you are unwilling to work around the problems you are creating then there is no tool on earth that can help you.

broodbucket 4mo ago

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

efilife 4mo ago
Didn't you mean "dissecting"? Edit: thanks guys, that's very useful knowledge! Could have saved me many times in the past
- jolmg 4mo ago
  man git-bisect
- seba_dos1 4mo ago
  Check out "man git-bisect".
- psadauskas 4mo ago
  Nope, `bisect`: https://git-scm.com/docs/git-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.

jhealy 4mo 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_username 4mo 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.

EPWN3D 4mo 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.

jxf 4mo 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 4mo 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 4mo ago
Do you really care if someone forgot to format before committing? They can always squash and push locally if they need to.
- locknitpicker 4mo ago
  > Do you really care if someone forgot to format before committing? Not OP but yes I definitely do. If you expect others to spend time reviewing your code, you are obligated to start off by reviewing it yourself. Posting a mess helps no one and makes code harder to audit.
- LtWorf 4mo ago
  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.
fcarraldo 4mo ago
Mine aren’t full of “oops” and “fix” messages, because I squashed them.
- bonzini 4mo ago

vcf 4mo 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 4mo 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 4mo ago

That is like saying once the program is done, throw away the source. Lemme guess all your for commit say "wip"

yjftsjthsd-h 4mo 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 4mo 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"

locknitpicker 4mo 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.

Izkata 4mo 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.

smcameron 4mo ago

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

nextlevelwizard 4mo 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

fragmede 4mo 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.

LtWorf 4mo ago

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

penguin_booze 4mo ago

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

aardvark179 4mo 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 4mo 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_ 4mo 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)

Hendrikto 4mo 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.

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

CuriouslyC 4mo ago

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

christophilus 4mo 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 4mo 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