3 ms·
> In my experience conflicts are not "usually due to very wide, mechanical changes", they're due to two people modifying the same file at the same time. Then i
by Peaker 9y ago
> In my experience conflicts are not "usually due to very wide, mechanical changes", they're due to two people modifying the same file at the same time.
Then it is likely a reversal of cause & effect. People are more reluctant to make wide sweeping changes such as renames because they're worried about the ensuing conflicts.
> Most projects don't go doing whitespace fixes over and over again
Again, for similar reasons. Projects limp around with broken indentation (tabs/spaces), trailing whitespaces, dos newlines, etc - because fixing whitespace is against policy. Why? Conflicts.
> You know what's even simpler? "Apply the same change to 1 version".
It sounds simpler, but not fucking it up is not simple at all, as evidenced by conflicts being a constant source of bugs.
When you look at the 3 versions, and "apply the diff to 1 version" you actually think you apply the diff to 1 version. You're applying the perceived diff to 1 version, which often differs from the actual diff as it may include subtle differences that aren't easily visible. This is detected by git-mediate the double-accounting of applying the perceived diff to both - validating that the perceived diff equals the actual diff.
Without git-mediate? At best you bring up build errors. At worst, revive old bugs that were subtly fixed in the diff you think you applied.
> then git-mediate just makes your job harder.
You're talking out of your ass here. Me and 20 other people have been using git-mediate and it's been a huge game changer for conflict resolution. Every single user I've talked to claims huge productivity/reliability benefits from using it.
> all you really need is a good merge tool
I've used "good" merge tools a lot. They're incredibly inferior to my favorite text editor:
* Text editing within them is tedious and terrible
* Their supported actions of copying whole lines from one version to the other are useless 90% of the time.
Let me ask you this:
What percentage of the big conflicts you resolve with a "good merge tool" - build & run correctly on the first run after resolution?
For git-mediate, that is easily >99%.
- eridius 9y ago> People are more reluctant to make wide sweeping changes such as renames because they're worried about the ensuing conflicts. I disagree. People generally don't do project-wide find&replaces because it's just not all that common to want to rename a global symbol. > Projects limp around with broken indentation (tabs/spaces), trailing whitespaces, dos newlines, etc - because fixing whitespace is against policy. Why? Conflicts. You seem to have completely missed the point of my comment. I'm not saying projects limp along with bad whitespace. I'm saying projects that decide upon whitespace rules typically do a single global fixup and then simply enforce whitespace rules on all new commits. That means you only ever have one conflict set due to applying whitespace policy, rather than doing it over and over again as you suggested. > You're applying the perceived diff to 1 version, which often differs from the actual diff as it may include subtle differences that aren't easily visible. Then you're using really shitty merge software. Any halfway-decent merge tool will highlight all the differences for you. > Without git-mediate? At best you bring up build errors. At worst, revive old bugs that were subtly fixed in the diff you think you applied. And this is just FUD. It's simple. Just stop using Notepad.exe to handle your merge conflicts and use an actual merge tool. It's pretty hard to miss a change when the tool highlights all the changes for you. > You're talking out of your ass here. And you're being uncivil. I'm done with this conversation.