Re: Git merge: conflict is expected, but not detected
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Nov 29, 2013, 18:37 UTC
- Message-ID
- <20131129183740.GB57602@vauxhall.crustytoothpaste.net>
- In-Reply-To
- <CAO6Ho0d=JHk4ydd1PdcWP1XHxvXpjfYVK+B_QLgd0vpyFTh_xQ@mail.gmail.com>
On Fri, Nov 29, 2013 at 06:26:25PM +0400, Evgeniy Ivanov wrote:
Show 11 quoted lines
> Hi! > > 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.
I don't believe so. The problem you're seeing is that by default, git considers only a small set of points for merges: the heads of the two branches and the merge base. So if one side has changed but the other has not, the changed code takes effect. This is not specifically a git problem, but a three-way merge problem in general.
If you rebase instead of merge, then the code ends up the way you want it, but this may or may not be appropriate for your workflow.
-- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187