Hi Holger, all, just to add that I effectively integrated this into the GitFileTree-MergeDriver, including adding the "mcmerge" merge tool inside the git configuration (where it is only used if you run the command `git merge-tool --tool=mcmerge`).
With this, you still keep the ability to interactively solve conflicts on smalltalk source code with another merge tool, such as meld. Thanks for finding a nice way of resolving metadata conflicts in `git cherry-pick` and `git rebase`! Regards, Thierry 2016-10-04 9:29 GMT+02:00 Holger Freyther <hol...@freyther.de>: > Good Morning, > > Thierry Goubier has merged a change to use the Pharo "merge" as a tool for > "git mergetool" and in this mail I explain how to configure it, give a > small example and explain my usecases for it. I am not sure the merge is > fully working and would like people to test and review (code and merge > results). > > > Configuration: > > edit ~/.gitconfig and put something like: > > [mergetool "mcmerge"] > cmd = /path/to/GitFileTree-MergeDriver/merge --mergetool $BASE > $LOCAL $REMOTE $MERGED > > > > Usage: > > $ git mergetool --tool=mcmerge > > > > > Use case: > > When using git merge to merge n branches, the GitFileTree-MergeDriver will > be consulted to merge the configured files. The same tools are not used > when git cherry-pick and git rebase fail to merge. In these case a manual > call of "git mergetool" is required. > > The following cases might be something you encounter. > > If you maintain a stable branch but want to backport a specific bugfix > from a master branch you might use "git cherry-pick <FIX_FROM_MASTER>" and > end with a merge conflict on the metadata. Using git mergetool > --tool=mcmerge will help you to resolve it. > > You try to contribute to a project that is using git for hosting and have > either been asked to modify your commits or the master version has been > updated while your code was under review. In this case you would issue "git > rebase origin/master". Metadata merge conflicts can be resolved with git > mergetool. > > For work I was creating a bugfix but when thinking of deployment I noticed > that I need to deploy in two phases. Roll-out the initial part of the fix > and once it runs everywhere start rolling out the actual bugfix. What I did > was splitting my bugfix branch in two, merge the first part into > repository. After it has been merged other changes were made before the > update was deployed. To continue to work on the second part of the bugfix I > rebased it and have used git mergetool to merge the metadata. > > > cheers > holger >
