Working with Git

[Rainer Müller]

On 2016-10-07 19:00, Brandon Allbery wrote:
> On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones <jonesc at hep.phy.cam.ac.uk
> <mailto:jonesc at 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