Revision: miles@gnu.org--gnu-2004/emacs--unicode--0--patch-35
authorMiles Bader <miles@gnu.org>
Sun, 5 Sep 2004 01:53:47 +0000 (01:53 +0000)
committerMiles Bader <miles@gnu.org>
Sun, 5 Sep 2004 01:53:47 +0000 (01:53 +0000)
commitdd6ab82fb5c85168043306deda1fa5a5010183c6
treeb3005de4b32c414ab30787c599860eec05fdb9d1
parent6f7dde8273383c74cc722196c9b37c04faeb263f
Revision: miles@gnu.org--gnu-2004/emacs--unicode--0--patch-35

Fix damage caused by trunk merge in emacs--unicode--0--patch-15

Some files in the emacs--cvs-trunk--0 branch had their arch id-tag changed
from tagline to explicit [because they were used as template files, and their
syntax didn't accommodate stripping comments, so the the generated files
caused id-tag conflicts when an in-tree build was done].

Unfortunately arch doesn't handle id-tag changes well, so this resulted in
the files appearing to be deleted, and then added again.  When that changeset
was merged into the unicode branch, it resulted in unicode-specific changes
being dropped, and the trunk version being added.

To fix this, I restored these files to their pre-merge versions (from
emacs--unicode--0--patch-14), and then manually reapplied all changes from:

  (1) the unicode branch from the bogus merge point to the current version
      (emacs--unicode--0--patch-15 - emacs--unicode--0--patch-34)

  (2) the trunk from the bogus merge point to the latest version which was
      merged into the unicode branch
      (emacs--cvs-trunk--0--patch-218 - emacs--cvs-trunk--0--patch-522)

and fixed any conflicts (mostly due to doubly-applied patch hunks that patch
couldn't detect).
leim/Makefile.in
lisp/makefile.w32-in
src/Makefile.in
src/makefile.w32-in