Merge algorithms

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > It's appropriate, but for some reason it refuses to merge the new
 > entries from the branch and declares them a conflict.  I don't
 > really understand why it should be a conflict.

They're not a conflict, and won't be declared a conflict, if the merge
to the ChangeLog is a fast-forward for that file.  So merges to
ChangeLogs in rarely changing subprojects are likely to go through
without conflict (if you keep separate ChangeLogs for them, of course).

In the case of parallel development, however, suppose that *at the
time of the branch* the latest ("top") log in ChangeLog is "LOG-0", so
ChangeLog looks like

LOG-0
... old logs ...

Now you do development and somebody else commits before you do.  Then
we have

mainline ChangeLog                Your ChangeLog

LOG-1                             LOG-2            # textual conflict!
LOG-0                             LOG-0
... old logs ...                  ... old logs ...

Both files have changed at the same place.  If you used context or
unified diffs and patch here, what would happen is that the "LOG-0"
context just below your patch would conflict with the "LOG-1" context
at the top of the mainline ChangeLog, patch would find "fuzz 0", and
refuse to apply the patch.