On Thursday, July 13, 2017 at 10:54:38 PM UTC+2, Philip Oakley wrote:

> I just want to comment on Buga's 
> > It`s not about what you retain, but what you drop -- with "checkout 
> --ours/theirs", you effectively drop all the changes from one of the 
> branches, and I didn`t get the impression that`s what the user wanted, as 
> he never mentioned that.
>  
> statement.
>  
> The "--ours/--theirs" options are not what we think they are!
>  
> They say that we should fully merge everything in the normal way, and only 
> if we have some minor local conflicts then Git should be biased to one side 
> or the other in terms of performing a perfect, *apparently* conflict-free, 
> merge.
>  
> So what you get is everyhing on master, and everything on INT, with just a 
> little bit of master's code missing where INT won coin toss (or the opposit 
> for the other option). 
>  
> I too had that misunderstanding for a while.
>

Just pay attention that we are talking about `git *checkout *--theirs 
<file>` here for solving conflicts that already appeared after `git merge`, 
in which case you nuke all the changes from one side, even those that would 
have otherwise be accepted through `git *merge *--strategy-option=theirs`, 
which seems to be what you`re talking about. It`s not the same.

And in case you`re not absolutely sure what you want to accomplish, `git 
merge --strategy-option=theirs` may be even worse, as you end up with some 
parts being merged cleanly from both sides (where there were no conflicts), 
and some parts totally dropping one of the sides (where conflicts 
appeared), as you already pointed out.

Regards,
Buga

----- Original Message ----- 
> *From:* Igor Djordjevic <javascript:> 
> *To:* Git for human beings <javascript:> 
> *Sent:* Thursday, July 13, 2017 8:58 PM
> *Subject:* Re: [git-users] Re: How to avoid merge conflicts while merging 
> INT changes into Master
>
> On Thursday, July 13, 2017 at 6:13:44 AM UTC+2, Maheshwaran A N wrote: 
>>
>> On Thursday, 13 July 2017 03:27:06 UTC+5:30, Igor Djordjevic wrote: 
>>>
>>> On Wednesday, July 12, 2017 at 6:38:35 PM UTC+2, Yubin Ruan wrote: 
>>>>
>>>> 2017-07-12 20:40 GMT+08:00 Maheshwaran A N <avpal...@gmail.com>: 
>>>>
>>> > On Tuesday, 11 July 2017 07:36:47 UTC+5:30, Anjaiah Yamagani wrote: 
>>>> >> 
>>>> >> Hi Team, 
>>>> >> 
>>>> >> I have very quick question - as I'm new to the git 
>>>> >> 
>>>> >> we have master branch. 
>>>> >> 
>>>> >> and checked out the INT branch from the master, worked on the INT 
>>>> for an 
>>>> >> month and all the developers pushed the code to INT , obviously INT 
>>>> branch 
>>>> >> ahead of comments then the master. 
>>>> >> 
>>>> >> Now while we try to push the code to the Master it shows conflicts, 
>>>> how to 
>>>> >> avoid this. 
>>>> >> 
>>>> >> at this stage I do not want to see the conflicts and work with the 
>>>> >> developers at this stage and resolve the merge conflicts. 
>>>> >> 
>>>> >> can you suggest are we doing any wrong thing here. 
>>>> >> 
>>>> >> Regards, 
>>>> >> Anjaiah
>>>
>>> >
>>>
>>> > I suppose you are trying to execute the below commands. 
>>>> > 
>>>> > git checkout master 
>>>> > git merge origin/INT (taking changes from remote branch)  or git 
>>>> merge INT 
>>>> > (merge with local changes) 
>>>> > At this point you would have faced the conflicts. 
>>>> > In this case, if you want to retain the changes of INT, you can take 
>>>> the 
>>>> > changes from INT and apply it in master without opening the file and 
>>>> solving 
>>>> > the conflicts. Execute the below command 
>>>> > 
>>>> > git checkout --theirs <path/to/conflictfiles> 
>>>>
>>>> wow, wasn't aware of that! Many thanks! 
>>>>
>>>> /Yubin 
>>>>
>>>> > git add <path/to/conflictfiles> 
>>>> > 
>>>> > Now, you can check in master branch for INT contents for conflicted 
>>>> file. 
>>>>
>>>
>>> I`m not sure how this helps resolving merge conflicts, as it doesn`t 
>>> only retain all changes from INT, but effectively nukes all changes from 
>>> master branch and just takes INT branch file state as-is -- so you`re not 
>>> "applying it in master", but deleting master changes altogether.
>>>
>>> Doing this is dangerous, unless you really want to drop all master 
>>> branch changes that happened since you branched your INT branch...
>>>
>>> Am I missing something?
>>>
>>> If this is exactly what you wanted to point out (dropping all master 
>>> changes and taking INT file as-is), then let this be just an additional 
>>> note of warning for those that might have missed it, as the original 
>>> question seems concerned with solving something else - a real merge 
>>> conflict situation, and this answer doesn`t seem to help there. 
>>>
>>> Regards,
>>> Buga 
>>>
>>  
>
> Requirement is to keep all the changes of INT. When you have multiple 
>> files to solve the conflicts and you very well know which branch to retain, 
>> then why not use ours/theirs? Whats dangerous here? User is very clear on 
>> what needs to be retained. 
>
>
> It`s not about what you retain, but what you drop -- with "checkout 
> --ours/theirs", you effectively drop all the changes from one of the 
> branches, and I didn`t get the impression that`s what the user wanted, as 
> he never mentioned that.
>
> He didn`t say he wants to retain INT changes in favor of master (loosing 
> master branch changes after the merge), but was merely asking how to deal 
> with merge conflicts which he doesn`t want to deal with _at the moment_ -- 
> and I`m afraid there`s no easy answer to this, as Philip already pointed 
> out.
>
> "Resolving" merge conflicts by using "checkout --theirs", he would drop 
> all the changes from master, not for the moment, but _for good_, and he 
> should be aware of that -- again, as it doesn`t seem that`s what he wanted, 
> thus it`s dangerous to propose without explaining all the implications.
>  
>
>> Also, if you retain INT content, there is no much impact in master since 
>> INT is branched out from master as a base(Ideally, master is untouched). 
>> Therefore, INT is master+newcontents and i hope thats well tested in INT 
>> branch itself. 
>>
>
> But it`s already pointed out that master is not untouched, otherwise there 
> would be no merge conflicts in the first place...
>
> Therefore, if you merge INT to master (both being changed), resolving 
> conflicts using "checkout --theirs" (taking INT over master), then INT will 
> be _INT only_ wherever there was a conflict with master -- meaning all the 
> file changes on the master side will be dropped.
>
> It doesn`t matter that INT was branched off master, as they both 
> progressed in the meantime... thus the merge conflicts.
>
> Let me use an example:
>
> (*1*) ---A---B---F---G---M (master)
>             \         /
>              C---D---E (INT)
>
> This shows the situation the user is having -- both branches progressed 
> since branching in commit B, and now merging "INT" to "master" in M raises 
> conflicts.
>
> To make it simple, lets say the project has only one file "main.c" which 
> has been modified in each commit.
>
> In this situation, if you resolve conflicts by doing `git checkout 
> --theirs main.c`, what you`ll end up in commit M is the exact same state of 
> "main.c" file as it was in branch "INT" (commit E), where all the changes 
> from the "master" branch (commits F and G) _would be lost_, not for the 
> moment, but forever.
>
> Even worse, in a more real life scenario where project usually has more 
> than one file, changes in files that raise no conflicts would be already 
> merged from "INT" to "master" successfully, thus by taking only "INT" side 
> for files that do have conflicts, you would end up in a possibly strange 
> situation of having some files with changes from both "INT" and "master", 
> and some files with changes from "INT" only (changes from "master" being 
> lost).
>
>  And, the original question is concerned with solving merge conflicts. I 
>> guess ours/theirs solves the purpose. 
>
>
> In general case, where you really want to merge two branches by keeping 
> changes made on both of them, no, it does not serve the purpose.
>
> Only if you want to pretend as one of the branches never existed, dropping 
> all its changes -- which is not what the user mentioned, and which is not 
> what you would _usually_ want to do with "master" branch, thus can be 
> dangerous, or confusing at least, if you`re not completely aware of what 
> you`re doing.
>
> Regards,
> Buga
>
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to