>
> On Monday, April 3, 2017 at 9:07:14 PM UTC+2, Pablo Rodríguez wrote:
>>
>> 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.
>>
>
*p.s.* In regards to this, it`s worth noting that concept of "latter
modified line", while actually pretty easily defined, might be done so
pretty unexpectedly for a new Git user.
Taking the previous e-mail laptop/desktop example further, one could
expect that a version done today on the desktop computer is clearly
an updated one in regards to a version made yesterday on the laptop
computer, and that there shouldn`t be any merge conflicts even if the
same line inside the file is modified on both sides (laptop/desktop)
- just take the newest file (time-wise) line version.
But for Git, that doesn`t have to be true at all.
As Git is distributed by nature, meaning that people can collaborate
rather _independently_ and _equally_ (no one`s version is "more
important" in Git`s eyes), a version isn`t considered to be "latest"
in terms of simple timestamps (when was the change made), but in
terms of history graph flow (which version on the graph the change is
connected to).
We just can`t expect that time is synchronized between different
computers so it realistically shows which version is really "newer".
But even if we could, Git still allows us to work on the changes
independently of all the others, of their changes and working pace,
so even if we make some change in our version after someone else did
(time-wise), that still doesn`t mean that we weren`t just slower to
produce our version, and that the other person didn`t provide what
should be considered an update in comparison to our work already.
Back to our laptop/desktop example. This is how could the history
graph look like:
D (laptop)
/
---A---B---C
\
E (desktop)
Version C is the last synchronized one, where versions D and E are
changes made on laptop and desktop respectively. No matter _when_
where versions D and E made (in comparison to each other), we must
not conclude anything from that - they are to be considered equally
important.
The only thing we know for certain here is that version B is newer
than version A, version C newer than version B, and versions D and E
newer than version C (but equally "new" in comparison to each other).
When attempting a merge M:
D
/ \
---A---B---C M (sync)
\ /
E
... all the rules explained in the previous e-mail apply, where the
same file line change in both version D and E raises a conflict,
unable to be automatically resolved by what could otherwise
unknowingly be perceived as a simple "latest/newest update" logic.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
