[Fire-Dragon-DoL]

I don't get it. Assuming your commits have meaningful messages and description, why squashing them? You can use git log --merges-only (I think that's the arg name) and all the sub commit are hidden, however you can still search through them to get a clear idea of why something was refactored a certain way.

So,where is the noise if it can be hidden but also used to get additional information on code changes?

[dakiol]

In my experience, when people need to know what commit belongs to what code, is the IDE the main driver: you see the line of code in the editor and automatically know what commit introduced it (e.g., via the git integration in the gutter). Typically you want to know as well all the other lines of code that were committed together (e.g., what does it take to implement feature X? Ah yeah, all these changes).

I couldn’t care less what changes were introduced in a particular commit (what for? Debugging? Your features should be small enough that debugging them shouldn’t be a pita anyway)

[baq]

If you need to use —-merges-only you might as well squash everything, why bother.

[Fire-Dragon-DoL]

I use merges-only when I need to look at the history "index" and I use the full history when I need to find out why a certain line was changed, kinda like a book has an index but there are also all the chapters with all the content