git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Really beginner on Version Control

From
Andrew Keller <andrew@kellerfarm.com>
Date
Sep 22, 2010, 03:52 UTC
Message-ID
<1AF8A1BC-1E52-4385-A0FC-16A04B4724FF@kellerfarm.com>
In-Reply-To
<1285114417273-5557145.post@n2.nabble.com>
On Sep 21, 2010, at 8:13 PM, FernandoBasso wrote:
Show 12 quoted lines
> 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
Previous: FernandoBassoNext: FernandoBasso
Message 10 of 17 in “Really beginner on Version Control”
  1. FernandoBassoSep 21, 2010
  2. Thomas MoulardSep 21, 2010
  3. Enrico WeigeltSep 21, 2010
  4. Eric RaibleSep 24, 2010
  5. Enrico WeigeltSep 24, 2010
  6. FernandoBassoSep 24, 2010
  7. Andreas EricssonSep 21, 2010
  8. Jakub NarebskiSep 21, 2010
  9. FernandoBassoSep 22, 2010
  10. Andrew KellerSep 22, 2010
  11. FernandoBassoSep 22, 2010
  12. FernandoBassoSep 22, 2010
  13. Tor ArntsenSep 22, 2010
  14. Dmitry PotapovSep 22, 2010
  15. Thomas HochsteinSep 22, 2010
  16. Dmitry PotapovSep 22, 2010
  17. Dmitry PotapovSep 22, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.