61–70 of 71 posts
To me this feels like making a commit without unit testing first. When I find a conflict I like to be able to resolve it and then do some unit testing to make sure that my revision didn't miss anything.
I suspect the use-case they have in mind are folks who have CI hooked up to Github (so using this feature will automatically trigger tests).
Earlier quoted context omitted.
I posted this in a comment above but because it's relevant I feel it's worth putting here as well[1]: git rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html "it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you." [1] This isn't explicitly against the rules but if it's in bad taste…
That's good if the exact same conflict reoccurs, but how often does that happen? What would be far better would be a syntax-aware version control system that knows about HTML attributes and understands how to combine two separate additions of HTML attributes.
Earlier quoted context omitted.
And you just lost git bisect
You can get it back by making your bisect test function return "good" whenever it sees a commit with merge conflicts.
That's a terrible idea and would completely break bisect. You should signal "skip" (return code 125) if the commit can not be tested at all.
Earlier quoted context omitted.
> serious stuff should be built and tested before pushing anyway Yes and no. Build in your CI server that's set up to mirror your prod environment after pushing, but before merging. That's what the whole industry of CI providers and integrations built into and around GitHub and GitLab is for.
To be fair, one of the annoying things about how PRs work is that they don't test the merge, they test the commit relative to its original base. Your tests may pass in the PR, but fail once applied to later changes in the main line.
Earlier quoted context omitted.
To be fair git could be given a tiny bit of "smarts" per language it's looking at. So say 2 different people add attributes to an HTML item it could use some sort of system that let's it run an HTML merge resolution routine that says "hey that's cool let me just combine those". At the same time adding extra smarts like that, while providing a better UX when it works , the times where it doesn't work especially if you…
I posted this in a comment above but because it's relevant I feel it's worth putting here as well[1]: git rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html "it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you." [1] This isn't explicitly against the rules but if it's in bad taste…
So simple, so useful, I wonder if this feature wasn't already in Gitlab since it seems to be more full featured
GitLab does have it already: https://docs.gitlab.com/ce/user/project/merge_requests/resol...
On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts in…
Earlier quoted context omitted.
I posted this in a comment above but because it's relevant I feel it's worth putting here as well[1]: git rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html "it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you." [1] This isn't explicitly against the rules but if it's in bad taste…
rerere is dangerous and not the solution. What I want is language-aware merge that can do things like "both these changes are just adding imports, adding in either order is fine" or "this change has added a parameter and this change has reformatted this line, I can add the parameter to the reformatted line".
Earlier quoted context omitted.
To be fair, one of the annoying things about how PRs work is that they don't test the merge, they test the commit relative to its original base. Your tests may pass in the PR, but fail once applied to later changes in the main line.
Most CI solutions will take care of that; they'll pull in the PR, merge it locally with master, and run tests on that .
Earlier quoted context omitted.
Most CI solutions will take care of that; they'll pull in the PR, merge it locally with master, and run tests on that .
I can't speak to the "merge-and-run" behavior of CI, but in my experience, most of these merge conflicts arise because of a time delay between making the PR (at which point CI is run) and merging the PR. It would be quite resource intensive to re-build every PR against every new branch in master.
Depends on just how resource intensive a build is, and how often commits are made to master.
Here at work, we don't do that, but it wouldn't be a complete clusterfuck if we were to.