Re: Git merge: conflict is expected, but not detected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 29, 2013, at 06:26, Evgeniy Ivanov wrote:
Let's say I have two identical branches: master and topic. In master I
remove some code, i.e. function bar(). In topic I do the same (commit)
and after some time I realize I need bar() and revert previous commit
with removal.
So I end with master with no bar() and topic with bar() in its
original state. When I merge I get code without bar() and no merge
conflict (recursive or resolve strategies). Is it possible to detect
such situations as conflicts? When bar() is C++ virtual there is no
possibility to catch this with compiler.

You can do something like:

git checkout master
git merge -s ours --no-commit topic
# conflicts, if any, will happen during cherry-pick
git cherry-pick --no-commit ..topic
git commit -m "Merge branch 'topic'"

Which will give you a merge commit as though using "git merge" but it will have restored the bar() function. However, depending on what's happened on the topic branch, you might have to wade through some conflicts that would not happen with a real "git merge" since cherry- pick will replay all the commits from the topic branch that aren't in master. Maybe some day "git merge" will grow a "--cherry-pick" option.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]