
A better pull request (2015) - yapdoggydog
https://developer.atlassian.com/blog/2015/01/a-better-pull-request/?categories=git
======
prodigal_erik
Conflict markers don't merit being included in the permanent history of a
project, and they break the build and prevent using tools like bisect. As a
dev, I'd rather pull the conflicting changes and resolve and test them in my
workspace than have to rewrite history to get rid of invalid commits. My
branch isn't ready to be reviewed and pulled unless it's up to date w.r.t.
master.

And the master branch (the starting point for new feature branches) should
contain the code that's _already_ released and vetted in production, not
whatever you _hope_ to release.

------
infodroid
I would find this incredibly annoying in the context of a code review if it
was the _only_ diff view available.

When performing a code review, I like to understand what changed on the branch
from merge base. The "tripe dot" diff is perfect for this because I don't want
to have to think about the new commits on master. That would make the pull
request diff appear different on every commit to master. This would be like a
constantly shifting kaleidoscope and would make it difficult to maintain a
fixed frame of reference during the review.

When assessing whether the code is good to merge, I also like to know how much
work there is left to do to integrate the changes back to master. And
Bitbucket's "phantom merge" is certainly useful in this regard.

But most of the time as a reviewer I want to see the "triple dot" view on the
pull request.

