Seth House wrote: > On Sun, Dec 20, 2020 at 11:34:24PM -0600, Felipe Contreras wrote: > > I disagree. It's fine if you don't want to participate, but the fact > > remains that the position that some tools would want to turn this off > > hasn't been properly defended. > > If you are _genuinely_ interested in the answer to this question, It's not about an answer to any specific question, defending a position requires for you to answer any subsequent questions, like the one I made here [1], which you never answered. > please read the section in my post titled "Conflict Resolution" > followed by the sub-section "Custom Merge Algorithm", and finally > "Merge algorithms" [1] on Wikipedia. > [1] https://en.wikipedia.org/wiki/Merge_(version_control)#Merge_algorithms I had already read your blog post, and OK; I read that section in Wikipedia. > Then pretend you want to write your own conflict resolution algorithm > for a new mergetool you've been dreaming up and ask yourself what > versions of the conflicted file your tool will need. I don't dream of writing my own conflict resolution algorithm, but if I did it, would be to be used *before* the mergetool, before git makes the decision to bother the user to resolve the conflicts manually, before it decides there are actual conflicts, and before it writes the conflict markers in the file. In fact, it would work without any mergetool, that way the people that like to edit the file directly (which you mentioned in your blog post are actually the majority of your coworkers) can benefit from such an algorithm. I answered yours, now you answer mine [1]. What happens if you remove the first paragraph of your make-conflicts.sh script? Would a user have the chance to run "git mergetool" in those situations? echo "The frumious bandersnatch!" > BASE echo "The frumious bandersnatch!" > LOCAL echo "The frumious Bandersnatch!" > REMOTE git merge-file -p LOCAL BASE REMOTE > Right now the algorithm Git uses is pretty best-in-class so it might > seem unlikely that someone would want to write one of those. And yet that's what Elijah Newren is doing with his merge-ort proposal which is flying right now. You want these algorithms to run in "git merge", not "git mergetool". > However a whopping *seven* of the tools surveyed do just that. Because they are used in other situations, like working with subversion, not just in git merge conflicts. > Some of them even do a pretty good job (I've tried to point those out > in the reviews). Better than git? > You're preoccupied with identifying a specific "adverse effect" but this > debate isn't about that -- it's about giving individual tools the option > to choose how they are used. Yes, individual *real* tools that either exist, or could actually exist. > If people out there want to try and write a better algorithm than Git, > I want to see them try. Yes, and we want that algorithm to be used *before* the mergetool. Moreover, if any merge algorithm hopes to do better than git, it would require more than just 3 versions of the file; it would require to look at the commit graph. If you somehow managed to create such an algorithm that is better than git, you certainly wouldn't give it out for free, and it wouldn't be on a puny mergetool to be used only when git thinks there are conflicts; it would be a solution to be used *at every merge*. And that's what a *real* tool, Plastic SCM [2], does; it's a complete solution that claims to have a better merge algorithm than Git. > That's the point I've been trying to drive home and that's the point > that David also made in his last reply to you. > > On that note: you replied to David and said: > > > [Y]ou spend your time implementing this on top of my patch. That way > > it's clear who made the mistake. > > I plan to start work on exactly that tomorrow. You made the initial > patch so if you'd prefer to take it over the finish line yourself I'll > defer. But if you're not interested then I would be happy to credit you > and finish it. It is already at the finish line (I just need to update the commit message). If you take my patch and add a bunch of unnecessary code, then remove my 'Signed-off-by' line, because I don't approve of those changes. Better yet; add *your* changes on a separate commit on top of my patch. That way it's clear who did the meat of the changes, and who did the unnecessary ones. > > Thanks for doing this, but unfortunately one of the most popular isn't > > listed there: vimdiff2. > > It's under the Vim section. Use the page search in your browser for > "vimdiff2". It says "The vimdiff, vimdiff3, and vimdiff2 mergetools are not individually detailed because they're all variations on the same theme". So yeah; no screenshots. And I disagree; vimdiff2 looks completely different from vimdiff. If you have to choose one, you should choose vimdiff2, which is what everyone in the reddit thread you posted on r/git told you they use, not vimdiff. You shouldn't deliberately chose the worst option that nobody uses. Moreover, the main view of your mergetool can be considered a variation also, I can replicate the behavior with the following vimdiff4: "$merge_tool_path" -f -d -c 'wincmd l | %d | read #1 | 1d | bd 1' \ "$LOCAL" "$MERGED" "$REMOTE" Does that mean diffconflicts shouldn't be listed either? Of course not; just add vimdiff2. Cheers. [1] https://lore.kernel.org/git/5fdd4f22c473b_1d952220844@natae.notmuch/ [2] http://blog.plasticscm.com/2011/09/merge-recursive-strategy.html -- Felipe Contreras
