Hi Stephen, There is another approach to merging, that is the 'imerge' tool [1], which does consider every commit on both sides of the merge.
It was developed for the cases where the two branches have diverged in many places. The 'i' in 'imerge' is a reference to it creating an incremental image of the merge process, so you can see where the individual commits have conflicts, so you can see where to investigate. It allows you (as I understand it) to picks points on the developing merge where there are no conflicts to use as the next commit point(s), so making useful progress quickly. Some of the discussion had somewhat diverged between the 'what has Git coded (for merge) and why does it choose to do it that way' and 'how and where should these (tricky) merges be approached from'. Neither is wrong per se, rather they are each right in their own context, but given that the contexts had divereged the approaches had likewise diverged.. I've not used imerge myself, but it has had some good responses. Philip [1] https://github.com/mhagger/git-imerge#git-imerge----incremental-merge-and-rebase-for-git see also the linked articles, video, presentation, etc. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
