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

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

 



Jon, Kyle, Brian,

Thanks a lot for your answers!

On Sat, Nov 30, 2013 at 12:51 PM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote:
> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Cheers,
Evgeniy
--
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]