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 <holger@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