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.
I think you'd want to skip, not mark as good?
Resolve simple merge conflicts on GitHub
51–60 of 71 posts
Re: Resolve simple merge conflicts on GitHub
#52Earlier quoted context omitted.
IMO, it is unnecessary to commit the conflicts. Instead, you can see how merges were resolved by diffing the commits.
"Diffing the commits" isn't really available in in a GitHub-style Pull Request web UI, which is where 99% of our code review is happening. I'm definitely optimizing for that view of the merge over everything else.
I love how github fosters discovery and remote collaboration, though one of its liabilities is when great git command-line features are effectively lost unless github re-implements or exposes them, because some conventions incentivize only doing what github itself can do.
Re: Resolve simple merge conflicts on GitHub
#53Earlier 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…
Git supports external merge tools (per file type too). They don't need to be packaged with the base install IMO, and git won't support every language under the sun. For example Unity3D are distributing one for their assets (which are not nice to merge as simple text)
For sure and I didn't mean they should necessarily be packaged with the base install either (though I'd argue as long as they're developed in a way that they can be updated you could provide a better UX bundling a few most common ones in). It's certainly doable though my only worry is them being almost smart enough and making a big mistake that isn't immediately noticeable.
Re: Resolve simple merge conflicts on GitHub
#54Earlier 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.
Most CI solutions will take care of that; they'll pull in the PR, merge it locally with master, and run tests on that.
Re: Resolve simple merge conflicts on GitHub
#55This is the dumbest shit I swear! GIT is super dumb when dealing with conflicts. Maybe GIT needs to get smarter. When another dev, and I work on the exact same line of code. I add a class, and he adds an ID. GIT goes like oh crap a conflict I have zero idea what to do! Here is a bunch of commented crap in your code, and let me tank grunt for you real quick.
I'd prefer it not be magic. Just because git COULD merge two of the same line changes doesn't mean it SHOULD. Maybe you have two vastly different methods to solving the same problem and now they are both in there and both not working instead of leaving it up to the merger to decide.
This seems like a clear case of unequal tradeoffs.
There are a couple of conflict patterns that are particularly easy to identify, which git could merge smoothly. For instance, two unrelated code blocks are appended to the bottom of the same file - whoever merged those two probably wants to keep both in any order.
But if you don't want that behavior, git is going to quietly auto-merge a bad change. That's easily 10x as bad as the time savings is good, maybe 100x. So I agree - this should not be magic, and I'm pretty sure the design for auto-merge hits practical limits long before technical ones.
Re: Resolve simple merge conflicts on GitHub
#56Earlier 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…
This is great, I appreciate you putting it here. I have a conflict pattern that comes up with enormous frequency at work, and for various reasons solving it somewhere other than the merge is not a great plan. It's always the same solution, though, and I could even predict it and flag for it in the commit message.
This seems like exactly the answer to that.
Re: Resolve simple merge conflicts on GitHub
#57To 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 think they explicitly say "simple merge conflicts" in the title. At the end of the day, you should use your own best judgement for when this is useful, and for when you need to go back to your workspace. It's most definitely not meant to be used for every merge conflict.
But not everyone is working on big projects with tests, and not every merge conflict is actually complex code modification.
Sometimes it's just two commits adding something at the end of the file and there's not real conflict, or maybe you modified the same line twice and forgot to pull before doing your 2nd edit.
Re: Resolve simple merge conflicts on GitHub
#58Earlier quoted context omitted.
Hmm. I usually do merges locally as serious stuff should be built and tested before pushing anyway, so probably why never used GitHub's hosted functions.
> 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.
And depending on setups, testing locally is testing far fewer environments than CI. I only have one laptop, but many of my projects need at least OS X, Linux, and Windows, and often multiple versions of those.
Re: Resolve simple merge conflicts on GitHub
#59Earlier quoted context omitted.
You can get it back by making your bisect test function return "good" whenever it sees a commit with merge conflicts.
I don't think that would work, but correct me if I'm wrong. As far as I know, git bisect does a binary search along the commits; `good` tells it to look at the latter half, `bad` to look at the former. So suppose you have five commits (1,2,3,4,5), where 1 is the working state, and 3 is a conflict commit. It will start by asking about the middle commit (3), automatically choose `good`, and determine that 3 was the lat…
This is resolved if you skip the commits with a conflict instead of marking as good.