Hi Pablo, On Monday, April 3, 2017 at 9:07:14 PM UTC+2, Pablo Rodríguez wrote: > > Dear list, > > although I have been using git for almost three years, I have used it > only for my writings (I cannot code). > > This reduces the need for branches and the possibility of merge > conflicts. I experienced less than five, due to the fact of working in > different computers (and having forgotten to sync repos the right way). > > My question is simple: what causes a merge conflict? > > I mean, changes in different files are merged fine, since the most > updated version of each is merged. > > I thought the same happened with different lines (the latter modified > line is kept in the merged file), but I can’t say for sure after > experiencing the merge conflicts. > > Could you confirm whether lines are merged independently or whether > there is always a conflict when one tries to pull a modified file from > remote in a file that was also modified after latest push in local? >
On top of what Konstantin already said, here`s an example. Let`s say you have a file "demo.txt" synced on both your laptop and desktop computer. The file contents may look like this: First Second Third Fourth Now, you edit the file on your laptop, and make it look like this: First > 2nd Third Fourth > 5th Later, you go to your desktop, forget to sync with your laptop first, but edit the file to look like this: First > Second best Third Fourth Now, if you try to sync/merge with your laptop, you`ll get a merge conflict... Important thing to notice here is that there is no merge conflict for the fifth line, Git will recognize that you added "5th" at the end of your file`s laptop version, and merge that happily, no conflicts. So, answering your question directly, yes, the file which was modified on both sides of the merge (local and remote, for example) can be merged without conflicts - as long as the changed lines are not overlapping... ... which brings us to the merged example file "Second" line, where the situation is not that clear - both laptop and desktop versions of the file changed it from original "Second" value. Should the merged version now be saying "2nd", "Second best", maybe "2nd best" or even something totally different...? Even if it may be pretty clear to you, Git can`t sensibly know that, and instead of trying to automatically do something which could be wrong, it complains about the conflict which you need to analyse and resolve yourself. In the end, I would just emphasize what Konstantin already mentioned as well, but in regards to the given example - Git doesn`t compare file lines by their _position_ in the file (second line vs. second line), as one might wrongly deduct from this simple demo, but rather by their _context_ (line between unchanged lines "First" and "Third" here, in reality taking several "context" lines before and after the changed one, for a good measure). This might be a common knowledge already, but could be worth a mention, just in case. To conclude, some more examples. If you started with the synchronized "demo.txt" file: First Second Third Fourth ... and made changes like this: Laptop: > Beginning > 0 First Second Third Fourth Desktop: First Second > 3rd Fourth ... your later merge attempt will not produce any conflicts, resulting in this: > Beginning > 0 First Second > 3rd Fourth Here, Git successfully recognized that you added some text before "First" line (lines "Beginning" and "0"), and that you also changed line "Third" to "3rd" - even though the line position is not the same any more, the context is, it`s still between unchanged lines "Second" and "Fourth". Another one, again starting with: First Second Third Fourth ... and making changes like this: Laptop: First > 2nd Third Fourth Desktop: First > 2nd best Third Fourth If you try to merge these two versions of the same file, you`ll end up with a merge conflict, as they both changed "Second" to "2nd" and "2nd best", respectively. Again, the solution might be clear to you, but if you think about it a bit, it may not be to anyone else (like Git, but even another human being), not knowing what you really wanted to accomplish in the first place (keep or remove the "best" part, for example)... Thus, you get a conflict, and the honors to resolve it manually in whatever way you prefer :) Hope all this helps a bit. 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.
