Re: Really beginner on Version Control

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

 



On Sep 21, 2010, at 8:13 PM, FernandoBasso wrote:

> I really appreciate your help. All of you. This is all starting to make sense
> to me thanks to you guys.
> 
> Now, what are the possible ways that we can get to a conflict when merging
> branches ? I'm doing some study tests, and some times I get conflicts, some
> times I don't. I couldn't really understand what causes them or not yet. 
> 
> For instance, I have 'hello' in line 2 of site.php in the master branch. I
> go to the  testing branch, edit site.php, change 'hello' for 'world' at the
> same line, commit and got back to master. I merge testing into master and I
> get no conflicts. Shouldn't it conflict ? (site.php in master also contains
> the string 'world' in the place of 'hello' now).

If I am understanding correctly, then this is an example of a fast-forward merge.

It sometimes helps to think of a series of commits as a series of changes, rather than a series of snapshots.  A merge conflict will occur when you *modify* overlapping sections of the same file in each branch.  The key word here is modify.  When you ask git to merge testing into master, you are not asking git to look at the code and figure out which one is "correct".  Instead, you are asking git to take the changes in testing, and the changes in master, each since they diverged, and create a new commit that incorporates both changes.

The only thing is, in your example, since master did not progress since testing diverged, git simply thinks of it as being "behind" testing, so you end up with a fast-forward merge, where master simply acquires the newer commits that testing has.  You can think of it as a special case optimization.  No need to make a merge commit if master is just behind and needs to be caught up.

If you would like to cause a merge conflict, then you should modify the same line of the same file in two different branches, and then try to merge the branches.  This is similar to what you just did, except that both master and testing must progress individually before you merge.

~ Andrew Keller

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