3 ms·
How is the PR author supposed to fix it without complex Git commands? Error prone copy and paste? I _really_ love working with Git, but in my experience engine
by wwright 7y ago
How is the PR author supposed to fix it without complex Git commands? Error prone copy and paste?
I _really_ love working with Git, but in my experience engineers unfortunately do need to tap into the long tail of “advanced” commands fairly often. At least often enough that they will quickly be frustrated by it.
(I’m currently helping move a bunch of our engineers from SVN to Git, and while I believe the better ecosystem will be worth it, it does break my heart every time someone has pointless trouble simply because of Git’s CLI.)
- 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.