[jamalaramala]

I think it is a good practice to clean up your branch before you merge it into master.

So instead of:

   * Change 1
   * Fix typo
   * Change 2
   * Another typo
   * Change 3
   * That didn't work
   * Ops, I did it again
   * Revert Change 3
   * Change 3 (final)

You'll merge:

   * Change 1
   * Change 2
   * Change 3

Which is much better, particularly if you have hundreds of developers working on the same codebase.

And it is very easy to do that using `git rebase -i`.

(I don't see the need for a GUI)

[xnorswap]

Okay, I guess this is also a consequence of having long lived branches that multiple people contribute to versus short-lived continuous integration into main.

I can also see value there if you're not squashing commits at the PR level. I prefer just squashing commits so main becomes:

  - Feature 1

  - Feature 2

  - BugFix 1

  - Feature 4

etc.

The individual branches have the "dirty" history which can be useful, and main is kept neat by having feature of fix-level changes which are quality controlled through gated-commits.

If you had to work on long-running feature branches which were more of a free-for-all so /branches/feature effectively becomes your "main" then I could see much more of an argument for re-writing history of individual contributors before merging into that feature branch.

I'd still argue you should just set up proper quality control on the feature branch and squash commits going into that, but that's the kind of overhead that can frustrate some teams, so I can better understand now the desire for a half-way cleaning between squashing and the full dirty history.

[WolfeReader]

I'd rather have the dirty history than the clean one. It seems really useful to have a record of an approach that didn't work, to save others from trying it again.

To see a "clean" history, I can always use log options like git's -first-parent. It works great and doesn't delete history.