On 2016-10-07 19:00, Brandon Allbery wrote: > On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones <jon...@hep.phy.cam.ac.uk > <mailto:jon...@hep.phy.cam.ac.uk>> wrote: > > Indeed, I was a little dubious of the suggestions that involve > -force. I suspect there are better ways of working that should avoid > the need for that. > > > --force only comes into it when you are rewriting history (i.e. merging > existing commits that were already sent upstream). Best is to not do > this; work in a branch, combine commits after, and cherrypick those to > *another* clean branch (or diff the first branch to get all changes as > one patch, and apply it in the new branch to get a single commit).
It would not be helpful to keep all commits from a pull request that took multiple iterations, that just adds clutter in the history and in the blame output. If you want to replace the commits in a pull request, it will require a 'git push --force' to the branch of the pull request. There is no way around it, except closing the pull request and submitting it as a new pull request, which breaks the connection to the previous discussion. > Or just accept multiple commits instead of trying to pretend to be a neat > freak after hosting a wild party. If the pull request just had a few fixups after the initial commit, that would be solved by squash merging everything into a single commit on the merge. However, a squash merge should not be used when multiple logical separated commits were submitted in a pull request (for example separate whitespace changes). Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
