2 ms·
> How is the PR author supposed to fix it without complex Git commands? Error prone copy and paste? Reclone from master (or the active branch if something else
by dspillett 7y ago
> How is the PR author supposed to fix it without complex Git commands? Error prone copy and paste?
Reclone from master (or the active branch if something else) to another directory, merge in their final changes, manually if needed, properly test the result, and sent a new PR with the cleaned up version?
(caveat: I've not used git in anger, there may be more to it than that, but I can't imagine much more)
I suppose who is responsible for dealing with cleaning up updates before merging them into the main project depends upon who wants it merged most: the PR submitter because they want a fix/change/other in upstream so they don't have to maintain their own fork, or the project maintainer because the update is more generally useful to other users or more specifically useful to the maintainer.
If you submit a badly arranged PR or other patch you are creating extra work for the project maintainer(s). Depending on the project and maintainer(s) this may be acceptable or, equally rightly, it may not.
- dwhitney 7y agoI've had engineers tap me on the shoulder with a proud look on their face while pointing at some crazy mess of branches they've just spent hours futzing with to finally get "right". It would have taken them a fraction of the time to just fix whatever issue they were having by following the advice above. People really take git histories WAY too seriously.
- dspillett 7y agoI can see the point of being pathologically protective of your own source history. But the project you are sending a PR to only really need to see the final effect of the changes. Of course for your own local history the same technique can work, you just keep the old branch as well as the newly cleaned one. Though that might be unnecessary clutter to many.