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.
Philip
----- Original Message -----
From: Igor Djordjevic
To: Git for human beings
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.
--
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.
