On Thursday, 9 February 2017 17:31:38 UTC-5, Philip Oakley wrote: > > 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. > >
Thanks Philip. Magnus already mentioned 'git imerge' on January 26th and I thanked him and wrote a reply about it on the 27th. Stephen -- 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.
