Actually I suspect that set of rules is from the SVN days where "commit" refers to what is called "merge" now in the Github days. Maybe the title should change and then the rules all re-examined?

@frlan yes, its good rule at the time of _merging_ a pull request, but squashing commits along the way leads to force-pushing which can cause problems. So its not something _contributors_ should do until the PR is accepted, but ...

... (as you said) github now provides good support squashing at merge (its the default big green button) so its even less important now.

@andy5995 pushed 1 commit.

a48e5e748426d2d092d8ba88c782f8ad9e8b0a52 HACKING:remove rule that shouldn't be used

I suggest to keep it, maybe rephrase a little that the PR author *should* squash at the end of the review in case there are to many iteration commits or "fixups" or so. When done only once at the end, the force-push shouldn't be so bad and the reviewer needs to diff on the diff only once (as @b4n said). So in the end the current rule keeps recommendation but it's not a must. And it depends on PR itself anyway.

@eht16 and @kugel- while I don't disagree, and as @kugel- said the author knows better what makes sensible commits (for me that means things that can be independent, the project needs to build and test with any commit or git bisect won't work). Just saying "squash" without any guidance is useless, I tend to squash everything into one since I have no idea what is independent and do not have the time to review and test to find out, especially with a big PR. So a merger might as well just hit the green button, thats what its there for.

But to inject a note of pragmatism, "When is the end?". How many times are last minute fixups added, all the time, so I would suggest squash and merge by author happen only _when the reviewer(s) agree_. Whilst @b4n's workflow is the ideal he noted its for git experts and we don't have many of those contributing to Geany.

Basically, making the process harder for either of authors or mergers is not a good idea for a project with so little effort available as Geany.

It sounds like what you'd prefer is that the submitter use something more like 'commit --amend' rather than having 3 or 4 tiny commits that follow larger commit. I've added some text to the section I removed that propose something to that effect. If you'd ultimately like something different, just use the [insert suggestion](https://til.hashrocket.com/posts/szgdi4at59-github-insert-a-suggestion-) feature.

Regarding using `git rebase --autosquash`, in my experience, it's much simpler to just use 'git reset <first commit>' and then [git commit --amend](https://www.atlassian.com/git/tutorials/rewriting-history). Just be sure to avoid using using 'git reset --hard' in that case! For example, if you have 4 commits on a feature branch, and you want the last 3 'squashed' into the first one, you can use 'git reset <1st commit>', then use 'git commit --amend ...' (see git docs for complete usage).

I have serious doubts that most regular git users or even maintainers are familiar with using rebase with autosquash and the --fixup directive. It seems a lot more trouble than it's worth for a feature branch (especially when maintainers can view a unified diff in any case). I'll concede that for those who have learned how to use it, it's probably no big deal. I first tried it a few weeks ago, and after a few tries, managed to squash my last commit into my 3rd to last commit. Last night I tried it, and somehow lost 20 minutes of work.

But I'm closing this PR now, since it's 3 years old and apparently not wanted, nor was it ever requested by the Geany maintainers.