threads / discuss / 35434

Git merge: conflict is expected, but not detected

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

## tl;dr

5 messages between Nov 29, 2013 and Dec 1, 2013.

replies: 4people: 4as markdown or json

Evgeniy Ivanov· Nov 29, 2013, 14:26 UTC · lore

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.

Please, CC me since I'm not subscribed.

Thanks in advance!

-- 
Cheers,
Evgeniy

brian m. carlson· Nov 29, 2013, 18:37 UTC · re: Evgeniy Ivanov · lore

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

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

Kyle J. McKay· Nov 30, 2013, 00:42 UTC · re: Evgeniy Ivanov · lore

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

On Nov 29, 2013, at 06:26, Evgeniy Ivanov wrote:

Show 9 quoted lines

> 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.

Jon Seymour· Nov 30, 2013, 08:51 UTC · re: Evgeniy Ivanov · lore

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

>From the perspective of topic there had been no change to the

definition of bar(), hence there was no change to contribute to the eventual merge with master.

One way to avoid this kind of problem is to avoid making (or cherry-picking) the same change on different branches, but instead use a merge of a branch with a common base to implement changes needed on multiple branches.

So, assuming you recognized the need to delete bar() from both topic and master, create a new branch from the merge-base of topic and master and delete bar() in that branch. Then merge this branch into both topic and master.

If you subsequently decide to revert the removal of bar() on topic then when you decide to merge topic back into master, git will see that the removal branch has been merged into both branches and will see the subsequent revert on topic as a change that needs to be merged and you will get the result you are looking for.

So, as a general rule of thumb, try to avoid making the same change on two different branches and instead factor out a change needed in multiple places into a separate branch which is then merged into the branches that need iit.

On Sat, Nov 30, 2013 at 1:26 AM, Evgeniy Ivanov <lolkaantimat@gmail.com> wrote:

Show 23 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.
>
> Please, CC me since I'm not subscribed.
>
> Thanks in advance!
>
> --
> Cheers,
> Evgeniy
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Evgeniy Ivanov· Dec 1, 2013, 11:02 UTC · re: Jon Seymour · lore

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

Jon, Kyle, Brian,

Thanks a lot for your answers!

On Sat, Nov 30, 2013 at 12:51 PM, Jon Seymour <jon.seymour@gmail.com> wrote:

Show 50 quoted lines

> From the perspective of topic there had been no change to the
> definition of bar(), hence there was no change to contribute to the
> eventual merge with master.
>
> One way to avoid this kind of problem is to avoid making (or
> cherry-picking) the same change on different branches, but instead use
> a merge of a branch with a common base to implement changes needed on
> multiple branches.
>
> So, assuming you recognized the need to delete bar() from both topic
> and master, create a new branch from the merge-base of topic and
> master and delete bar() in that branch. Then merge this branch into
> both topic and master.
>
> If you subsequently decide to revert the removal of bar() on topic
> then when you decide to merge topic back into master, git will see
> that the removal branch has been merged into both branches and will
> see the subsequent revert on topic as a change that needs to be merged
> and you will get the result you are looking for.
>
> So, as a general rule of thumb, try to avoid making the same change on
> two different branches and instead factor out a change needed in
> multiple places into a separate branch which is then merged into the
> branches that need iit.
>
>
> On Sat, Nov 30, 2013 at 1:26 AM, Evgeniy Ivanov <lolkaantimat@gmail.com> wrote:
>> 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.
>>
>> Please, CC me since I'm not subscribed.
>>
>> Thanks in advance!
>>
>> --
>> Cheers,
>> Evgeniy
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Cheers,
Evgeniy