1 commit == 1 reviewable unit == 1 PR == 1 CL == 1 feature == 1 fix is a perfectly reasonable way of working.

I used to work at companies where no one squashed their commits and the entire git logs were filled with 80% non-sense like "temp" or "bad" or "working" with the other 20% being coherent changes. What's the point of doing this I ask?

▲

zmmmmm 28 minutes ago | parent | next [-]

there is an inbetween .... i insist people interactively rebase those commits out. In some contexts it is actually important to have traceability of iterative proof of work towards the final result.

▲

datsci_est_2015 4 hours ago | parent | prev | next [-]

Well are we talking about commits pre- or post-merge? I don’t care how many commits you put into the PR / MR as long as they squash down to a single commit upon merge.

	▲	steveklabnik 4 hours ago \| parent [-]
		When you work this way, each commit is expected to be able to land independently.

▲

cobalt 4 hours ago | parent | prev [-]

it lets you maintain version history when working, then most workflows auto squash on merge