Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.

> 4 actually never really ran in production?

but the history showed that it was tried (and perhaps the commit message can have a short note on why it wasn't selected).

without the git history, you'd have to rely on human memory to know this. Or a separately maintained documentation (which, lets face it, is never going to get updated).

Or store it in another branch - that's the approach we had been using in one company I worked at.

Ah, yes, this was implied :) only working code (as checked via CI) is allowed to show up in master and other long living branches.

This is much easier when I actually need to trawl through history to find things.

I think there are two perfectly acceptable schools of thought.

One says that the history should be preserved exactly, because its important we keep a record of exactly what happened.

The second says that its ok to rewrite history a little if that makes it more understandable.

I think you would put yourself in the first, and that's ok. I would put myself in the second because at the end of the day I value understanding over precision in git histories. I'm of the opinion that one cares about the commit I made to correct a missing semicolon.

The usual rule of thumb is not to modify (e.g rebase) published commits. So it's perfectly fine to adjust local commits before they go into centralized repo - from the point of view of an external observer the history is never destructively modified. This rule can be extended to topic branches or user owned branches with the caveat that others should not base their work upon the topic branch.

Also remember git push --force-with-lease!

And `git commit --amend`

I missed a semi-colon or a file? I probably noticed right after I made the commit (and before I pushed it to the remote branch).

I am in the first because I don't think you should change history. But I think there is a need for tools that can show history like it would look after rebasing and squashing.

Maybe we need another layer of abstraction, maybe recorded as merge commits, that would present the summarized history.

I really don't need to see all your false starts at a solution to the problem. I don't mean that in a patronizing way, it's just that it is truly irrelevant when I'm digging through commit history.

Question: Do you have a problem with rebase-before-push?

Regardless, there's a happy medium here: Just commit whenever you feel like it, then rebase, squash or whatever just before you're reasonably(!) confident in your approach... and push. Obviously you don't want to force-push, so at the point that you're "reasonably confident" you're committed. If you need to retrace your steps, you just do that through normal "git revert" or whatever.

The point of the above being: This way of working preserves the useful parts of history and you still avoid the absurd noise of seeing everybody's "I changed a thing" commits and non-compiling-commits as well.

The thing is I commit very frequently, and a lot of the commits don't really make much sense by themselves. Often with stuff that's just plain wrong or confusing inbetween.

e.g. remove console.log

what do you need that in the git history for?

“Fix lint” is my favorite one.

My unfavorite is WIP and "update submodule(s)". In fact I contemplated making a git hook to reject such drivel on merge.

I wish there was some happy medium, like that I can merge a branch and it gets squashed into a single commit, but then if needed I can 'expand' that commit to see its contents, even after the other branch is deleted.

That’s a rebased branch. You can see just the changed introduced by a branch:

  MERGE_COMMIT=$(git rev-parse :/“Merge .*$branchname”)
  git diff $MERGE_COMMIT^1..$MERGE_COMMIT^2

It never occurred to me that people prefer to squash so they can avoid the crummy UI of git diff