4

Common scenario: A contributor sends a pull request containing 1 or 2 useful changes plus a ton of (unwanted by me) whitespace changes made automatically by his IDE.

Of course I can tell him to adjust his IDE, and to use tools like GitX to stage specific changes before committing, but the damage is done; either he has to re-commit & force push, I have to accept all the changes, or one of us has to add an "undo" commit before merging.

Is there an easier way?

Ideally I could merge just like the commit process in GitX: I could unstage specific changes from the branch, and the tool would either auto-rewrite the commits or make an "undo" commit before merging.

Steve Clay
  • 8,671
  • 2
  • 42
  • 48
  • To clarify, I'm looking for a solution that allows me to accept the merge (with a little scolding) with minimal pain. Policy change/enforcement doesn't really answer my question. – Steve Clay Apr 11 '13 at 23:02
  • E.g. a tool that checks out the PR, then makes file changes that would reverse all the changes made in the PR. Then I could selectively stage/commit the "undo" changes, commit, and merge. – Steve Clay Apr 11 '13 at 23:07

2 Answers2

1

You get rid of the whitespace changes locally, the developer will see all the whitespace changes you didn't accept as changes against her version, and so on. Just misery spread all around.

The only way out is to agree on one whitespace style (perhaps enforced by the tools, or done by external tools before commiting). Uniformly for all.

vonbrand
  • 11,412
  • 8
  • 32
  • 52
0

Personally, I would tell the contributor to make the changes and recommit + force push the changes. Since the contributor is probably working on a feature branch in a fork of your repo (the "origin"), nobody is following his commits. There is no real damage if the contributor rewrites the history on a branch that nobody is following and that will probably be deleted after you pull the changes in. For that matter, the contributor could also create a new feature branch which has the final merge-able changes, make a new pull request, and delete the old branch and pull request (so that there is no history rewriting).

Ivan Zuzak
  • 18,068
  • 3
  • 69
  • 61