It would make me happy if SublimeGit was better at showing merge conflicts. I feel like I only know they exist when I'm surprised that my build is now broken, and my only resolution is to Find in Project for `>>>>>` and hope I catch all of them.
A better pull request
11–20 of 167 posts
Re: A better pull request
#12I really like the idea of merge conflicts being resolved in the open in a pull request, instead of the pull requester working in seclusion. For those of us with projects on GitHub, is there any way to replicate this behavior there?
A common practice is for pull requesters to rebase their branch on the upstream branch to avoid these conflicts.
Re: A better pull request
#13Interestingly, only Github manages to syntax highlight the diff.
Re: A better pull request
#14I agree this is a better way to look at pull requests, but I'm surprised it's as much of a problem as the post implies. For us, whenever we do a pull request, we always rebase against the latest master first. That can be a cat and mouse game, but it usually isn't. Our repos don't change that rapidly.
Re: A better pull request
#15It would make me happy if SublimeGit was better at showing merge conflicts. I feel like I only know they exist when I'm surprised that my build is now broken, and my only resolution is to Find in Project for `>>>>>` and hope I catch all of them.
It'd make me happy if SublimeGit fixed the pull issues on OSX, let alone any update :(
Re: A better pull request
#16It would make me happy if SublimeGit was better at showing merge conflicts. I feel like I only know they exist when I'm surprised that my build is now broken, and my only resolution is to Find in Project for `>>>>>` and hope I catch all of them.
git status will tell you which files are conflicted.
Re: A better pull request
#17Earlier quoted context omitted.
But still the test would only fail after the merge, whereas you'd want to catch this before.
On GitHub you can have tests run before you've merged, so you know whether it's safe or not.
Don't the tests just run on the branch before the merge? If so, you wouldn't actually see the failure until after you merge.
Re: A better pull request
#18This is so telling: GitHub had a blog post yesterday[1] about pull requests and now Atlassian does today with a very similar title. The one from GitHub was about social dynamics and how to work together better, while the one from Atlassian is about technical minutiae.
Having used both GitHub and Stash, the difference in focus between the two companies comes across plainly, and these two blog posts only back it up.
[1]: https://github.com/blog/1943-how-to-write-the-perfect-pull-r...
Re: A better pull request
#19Very interesting, I never considered looking at the conflicts that way. It might be helpful to allow looking at the conflicts in the diff3 conflict marker style. The advantage is that you get to see the common ancestor, which can be crucial to figuring out a tricky merge.
git config --global merge.conflictstyle diff3
Re: A better pull request
#20I agree this is a better way to look at pull requests, but I'm surprised it's as much of a problem as the post implies. For us, whenever we do a pull request, we always rebase against the latest master first. That can be a cat and mouse game, but it usually isn't. Our repos don't change that rapidly.
The problem is, many pull requests take very long to get merged (because of the size of the PR, the review process, etc.), and by the time that they are ready to be merged, the target branch could very well have changed.