On 2017-02-09, at 5:36 PM, Stephen Morton <stephen.c.mor...@gmail.com> wrote:
> 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 I have been following this discussion, and reading about iMerge since it was mentioned here. I see one big difference: Normal merge only considers the heads, and the common base iMerge considers every commit along the way. The idea of "Both branches got a change, and in one it was removed because it doesn't work" results in normal merge bringing it back (it is present in one of the heads) (the removal is removed), but imerge still gives the removal a chance to show up. Equally, in that "conflicted branch with resolutions" case, imerge would see the conflicts and want you to re-resolve them again. (... redundant statement?) I guess that the question of whether or not to use imerge depends on how you do your merging. If the merge is done on a special resolution branch -- i.e., something like: 1. Branch master at old point A 2. Long development on newbranch to point B 3. Long development on master to point C 4. Attempting to merge gives too big of a conflict, and is aborted. 5. Branch master at C to resolution. 6. Merge newbranch into resolution. Commit all the conflicts. 7. Have many different workers work on resolving all conflict markers in resolution, until the code is conflict free and compiles again. 8. Now merge this new branch into master -- then you get the benefits of "iMerge" of being able to share your conflict resolution with others, but lose the benefit of each stage being incrementally simple and testable. On the other hand, you might gain a more readable/understandable cleanup changelog/history. But the two strategies -- using imerge, or using a resolution branch -- seem to be fundamentally opposed. Has anyone actually tried both different methods, that can describe which has worked better? (p.s.: Is it spelled "imerge" or "iMerge", or "Imerge", or ... ?) --- Entertaining minecraft videos http://YouTube.com/keybounce -- 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.
