[lukicdarkoo]

In my workflow, I typically commit often and use the commits as personal checkpoints. Once a pull request is ready I simply squash the commits and merge. That way, the history in the main branch is clean and I have my checkpoints. I assume that is a typical workflow for many teams.

[juped]

Assuming you're referring to something like the github "squash and merge" button, your history is far from "clean". You make it significantly less useful by destroying information and creating megadiffs incorporating many different changes.

Instead, do what you want with personal checkpoints, but refactor them into logical steps before publishing and merging (with a real merge) them.

[fuzzy2]

> You make it significantly less useful by destroying information and creating megadiffs incorporating many different changes.

You’ll rarely review single commits anyway. However, I’d rather have a single “giga-commit” instead of dozens of commits that are not correctly divided plus dozens of “remarks from code review” commits because what’s rebase.

Many of my colleagues view using Git not as part of their core work but an inconvenient chore.

[juped]

> You’ll rarely review single commits anyway.

This is just because Github and its imitators are bad software - which isn't really git's fault. git and Linux practice only commit-level review.

> Many of my colleagues view using Git not as part of their core work but an inconvenient chore.

Many people don't care about version history, and ignorance of how git works (or adherence to superstitious rulesets) on the part of the people who do care provides them cover for trashing the history.

Many people don't care about code quality or maintainability. However, these people are more likely to be prevented from trashing the codebase itself than the ones who don't care about history are from trashing the history.

Commit history is just as subject to review as the contents of diffs.

[fuzzy2]

> git and Linux practice only commit-level review.

I don’t think that’s an accurate way to put it. AFAIK you just send in patch files. They create a single commit, yes, but I see it as equivalent to a PR. The rules of what can be in a single patch could be stricter than typical PRs on other projects, dunno.

> Commit history is just as subject to review as the contents of diffs.

I wish. Maybe I’ll work on a better team on the future.

[juped]

what I mean is, take any arbitrary patch thread off the front page of https://public-inbox.org/git/ and look at how people review them. they reply to the relevant commit. if you reply to the cover letter it's not a code review at all, but a more general comment on the whole branch (e.g., "do we want this feature" or something).

you definitely don't send your branch as a single patch (unless it is small and really is best expressed as a single patch). if you did you would be asked to break it up.

[lukicdarkoo]

The squash and merge button is convenient, but not the only way. As you mentioned, sometimes I do squashing locally into multiple meaningful commits. It's important that my mess doesn't end up in the main branch. Also, another approach would be creating smaller pull requests.

[juped]

the size of your branch doesn't matter, if it really is logically separable into a lot of changes. what matters is usefulness to the future reader (you, or someone else). lowering the number of commits for its own sake makes things less useful, not more, by destroying useful information.

you are correct to realize that e.g. "my working directory as of this timestamp when i got up from my computer" is not useful information, and should not be published. however, a diff that does too many things at once is also not useful information - you are forcing the reader to separate it themselves, possibly wrongly, every time they read the diff. very few branches in actual practical work are organically one commit long in their most useful expression.

finally, the merge to upstream is useful information, as the only source of a high-level view of the progression towards a release, and if you (i'm only guessing because of the use of the "clean history" shibboleth) avoid actual merges (with merge commits) to upstream, you're destroying important information about the integration work of the project, making the history significantly messier (from the perspective of someone reading it, which is the only perspective that matters).

(at the advanced level of writing-history-for-usefulness, you also realize that random-place-on-master branch starting points are not useful information, and learn where to start them from, but this is low-impact in comparison to not destroying branches. still, learning things like "base a bugfix on the commit that introduced the bug" are real force multipliers.)