Hello Paul, Paul Gevers [2018-04-06 10:04 +0200]: > Until recently I considered pushing an altered history to a public > repository not done. FTR, as a heavy GitHub user I'm quite at the opposite camp. At least in the Cockpit, Systemd, and python-dbusmock projects, user/topic branches get rebased and mangled all the time to respond to pull request reviews, and eventually end up with a clean patch series. Of course "master" should be holy and never force-pushed unless there's some sort of accident. > - No force-pushing on the master branch¹ > - Alterations are allowed on topic branches > - Alterations on topic branches and re-basing of topic branches on the > master branch are recommended to improve the quality of the commits via > reviews that get merged or applied in the master branch That indeed seems to be the standard workflow in the git PR world, so big +1 from me. > - [unsure] topic branches can be either merged or rebased on top of > master before adding to the master branch That I figure is another vim vs. emacs topic :-) Personally I don't like the merge commits as they clutter up git log and don't really give you anything, and I just prefer a linear history. But different projects handle this differently. For example, in systemd PRs that consist just of a single commit get "squashed", i. e. rebased on top of master with an altered commit message that adds the PR # number. Multi-commit PRs get landed in "merge" mode with an additional merge commit that points to the PR. OTOH, in Cockpit we avoid merge commits altogether and instead manually add the "Closes #1234" tag to commit messages and use "Rebase" mode (and for single-commit PRs, squashing as that's the common and easy case). I'd say: pragmatism, common sense, and not overthinking it :-) Martin
Attachment:
signature.asc
Description: PGP signature