Merge algorithms

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen at xemacs.org>
 > > Cc: john at arbash-meinel.com,
 > >     mbp at canonical.com,
 > >     bazaar at lists.canonical.com
 > > Date: Sat, 18 Sep 2010 23:36:12 +0900
 > > 
 > > Eli Zaretskii writes:
 > > 
 > >  > No, there will be no corruption, because when I merge from
 > >  > mainline, I need to edit the logs anyway.
 > > Eli, it's not about *you* Eli, it's about you Emacs developers,
 > > some of whom are are far less careful than you Eli are.
 > 
 > When I say "I" above, I don't mean Eli, either.

Ah, but do you mean the guy who has already twice managed to push his
personal libraries and local changes into the public mainstream?

Linear ChangeLogs in a DVCS world are an anachronism.  Log
presentation should branch and merge just as the history it describes
does.  That's what pretty much everybody who has thought carefully
about the problem after experiencing modern VCS (and this line of
thought goes back to CVS) has decided.

Since Aaron thinks he can write such a plugin easily, more power to
him, and I hope you make good use of it.  But I have to think that
spending effort to get rid of the ChangeLog-based workflow would be a
better investment all around.

VCS-based Emacs contributors have all switched to Bazaar, so they can
generate a global ChangeLog file easily, and would probably be just as
happy to get rid of the ChangeLog entry task in favor of the commit
message.  diff/patch users have the option of using -U0 diffs on log
entries (Didier Verna's patcher.el automates this) or simply writing a
separate log entry which the committer can copy into the commit message.

You can still have a ChangeLog file, of course; it's just that it
would be a generated files rather than a source file.  This is of
course the somewhat complex part, since Emacs has per-directory logs.
But it shouldn't be *that* hard.