* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
[not found] <E1XYpeB-0002D6-5f@vcs.savannah.gnu.org>
@ 2014-09-30 15:56 ` Stefan Monnier
2014-09-30 16:23 ` Bill Wohler
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-09-30 15:56 UTC (permalink / raw)
To: Bill Wohler; +Cc: emacs-devel
Hi Bill,
Don't do this. Your commit says you "merged" but the metadata says
you didn't. You just duplicated the changes that you previously
installed on emacs-24. So that'll just create spurious conflicts when
we do merge the emacs-24 changes into trunk.
You can merge things from emacs-24 to trunk if you want (and we always
welcome people to do that, so that we don't have to), but you have to do
it with a plain "bzr merge" or with "M-x bzrmerge" (from
emacs/admin/bzrmerge.el), the latter being a more clever version of the
former which knows about some of our coding conventions.
Stefan
>>>>> "Bill" == Bill Wohler <wohler@newt.com> writes:
> ------------------------------------------------------------
> revno: 117980
> revision-id: wohler@newt.com-20140930050642-14nctsd0lavynqwi
> parent: wohler@newt.com-20140930045810-hty0uyvr82ww5p3p
> committer: Bill Wohler <wohler@newt.com>
> branch nick: trunk
> timestamp: Mon 2014-09-29 22:06:42 -0700
> message:
> Merge from emacs-24; up to r117522.
> modified:
> etc/MH-E-NEWS mhenews-20091113204419-o5vbwnq5f7feedwu-1489
> etc/NEWS news-20100311060928-aoit31wvzf25yr1z-1
> lisp/mh-e/ChangeLog changelog-20091113204419-o5vbwnq5f7feedwu-2547
> lisp/mh-e/mh-comp.el mhcomp.el-20091113204419-o5vbwnq5f7feedwu-2532
> lisp/mh-e/mh-e.el mhe.el-20091113204419-o5vbwnq5f7feedwu-2534
> === modified file 'etc/MH-E-NEWS'
> --- a/etc/MH-E-NEWS 2014-01-16 06:24:06 +0000
> +++ b/etc/MH-E-NEWS 2014-09-30 05:06:42 +0000
> @@ -3,6 +3,28 @@
> Copyright (C) 2001-2014 Free Software Foundation, Inc.
> See the end of the file for license conditions.
> +* Changes in MH-E 8.6
> +
> +Version 8.6 fixes composition errors in nmh 1.6.
> +
> +** Bug Fixes in MH-E 8.6
> +
> +*** Add support for nmh 1.5
> +
> +A components file is now generated that works with nmh 1.5 (partially
> +closes SF #468).
> +
> +*** Error if mh-x-face-file is nil
> +
> +Ensure that `mh-x-face-file' is a string before trying to use it
> +(closes SF #474).
> +
> +*** MH-Folder buffer includes "scan: bad message list unseen"
> +
> +Fix this error (closes SF #471).
> +
> +\f
> +
> * Changes in MH-E 8.5
> Version 8.5 fixes bugs when incorporating or forwarding mail.
> === modified file 'etc/NEWS'
> --- a/etc/NEWS 2014-09-29 18:14:08 +0000
> +++ b/etc/NEWS 2014-09-30 05:06:42 +0000
> @@ -918,7 +918,7 @@
> *** Recognition and better indentation of continuations in array comprehensions.
> -** MH-E has been updated to version 8.5 - see separate MH-E-NEWS file.
> +** MH-E has been updated to version 8.6 - see separate MH-E-NEWS file.
> ** Octave mode
> === modified file 'lisp/mh-e/ChangeLog'
> --- a/lisp/mh-e/ChangeLog 2014-05-09 07:02:00 +0000
> +++ b/lisp/mh-e/ChangeLog 2014-09-30 05:06:42 +0000
> @@ -1,3 +1,21 @@
> +2014-09-30 Bill Wohler <wohler@newt.com>
> +
> + Release MH-E version 8.6.
> +
> + * mh-e.el (Version, mh-version): Update for release 8.6.
> +
> +2014-09-30 Mike Kupfer <m.kupfer@acm.org>
> +
> + * mh-comp.el (mh-insert-x-face): Ensure that mh-x-face-file is a
> + string before trying to use it (closes SF #474).
> + (mh-bare-components): New function to create a temporary initial
> + components file; replaces mh-find-components. Improve the temp
> + folder and file names as per a suggestion from Bill Wohler. Also
> + address XEmacs compatibility issues: use mm-make-temp-file instead
> + of make-temp-file, and only pass one argument to delete-directory.
> + (mh-edit-again, mh-send-sub): Use mh-bare-components instead of
> + mh-find-components (partially closes SF #468).
> +
> 2014-05-09 Glenn Morris <rgm@gnu.org>
> * mh-e.el (mh-variants): Use file-accessible-directory-p.
> === modified file 'lisp/mh-e/mh-comp.el'
> --- a/lisp/mh-e/mh-comp.el 2014-01-01 07:43:34 +0000
> +++ b/lisp/mh-e/mh-comp.el 2014-09-30 05:06:42 +0000
> @@ -411,6 +411,7 @@
> (interactive (list (mh-get-msg-num t)))
> (let* ((from-folder mh-current-folder)
> (config (current-window-configuration))
> + (components-file (mh-bare-components))
> (draft
> (cond ((and mh-draft-folder (equal from-folder mh-draft-folder))
> (pop-to-buffer (find-file-noselect (mh-msg-filename message))
> @@ -467,7 +468,8 @@
> ;; Text field, that's an easy case
> (t
> (mh-modify-header-field field value))))))
> - (mh-components-to-list (mh-find-components)))
> + (mh-components-to-list components-file))
> + (delete-file components-file)
> (goto-char (point-min))
> (save-buffer)
> (mh-compose-and-send-mail
> @@ -885,22 +887,6 @@
> (t
> nil))))
> -(defun mh-find-components ()
> - "Return the path to the components file."
> - (let (components)
> - (cond
> - ((file-exists-p
> - (setq components
> - (expand-file-name mh-comp-formfile mh-user-path)))
> - components)
> - ((file-exists-p
> - (setq components
> - (expand-file-name mh-comp-formfile mh-lib)))
> - components)
> - (t
> - (error "Can't find %s in %s or %s"
> - mh-comp-formfile mh-user-path mh-lib)))))
> -
> (defun mh-send-sub (to cc subject config)
> "Do the real work of composing and sending a letter.
> Expects the TO, CC, and SUBJECT fields as arguments.
> @@ -910,8 +896,8 @@
> (message "Composing a message...")
> (let ((draft (mh-read-draft
> "message"
> - (mh-find-components)
> - nil)))
> + (mh-bare-components)
> + t)))
> (mh-insert-fields "To:" to "Subject:" subject "Cc:" cc)
> (goto-char (point-max))
> (mh-compose-and-send-mail draft "" folder msg-num
> @@ -920,6 +906,29 @@
> (mh-letter-mode-message)
> (mh-letter-adjust-point))))
> +(defun mh-bare-components ()
> + "Generate a temporary, clean components file and return its path."
> + ;; Let comp(1) create the skeleton for us. This is particularly
> + ;; important with nmh-1.5, because its default "components" needs
> + ;; some processing before it can be used. Unfortunately, comp(1)
> + ;; doesn't have a -build option. So, to avoid the possibility of
> + ;; clobbering an existing draft, create a temporary directory and
> + ;; use it as the drafts folder. Then copy the skeleton to a regular
> + ;; temp file, and return the regular temp file.
> + (let (new
> + (temp-folder (mm-make-temp-file
> + (concat mh-user-path "draftfolder.") t)))
> + (mh-exec-cmd "comp" "-nowhatnowproc"
> + "-draftfolder" (format "+%s"
> + (file-name-nondirectory temp-folder))
> + (if (stringp mh-comp-formfile)
> + (list "-form" mh-comp-formfile)))
> + (setq new (mm-make-temp-file "comp."))
> + (rename-file (concat temp-folder "/" "1") new t)
> + (delete-file (concat temp-folder "/" ".mh_sequences"))
> + (delete-directory temp-folder)
> + new))
> +
> (defun mh-read-draft (use initial-contents delete-contents-file)
> "Read draft file into a draft buffer and make that buffer the current one.
> @@ -1069,7 +1078,8 @@
> (defun mh-insert-x-face ()
> "Append X-Face, Face or X-Image-URL field to header.
> If the field already exists, this function does nothing."
> - (when (and (file-exists-p mh-x-face-file)
> + (when (and (stringp mh-x-face-file)
> + (file-exists-p mh-x-face-file)
> (file-readable-p mh-x-face-file))
> (save-excursion
> (unless (or (mh-position-on-field "X-Face")
> === modified file 'lisp/mh-e/mh-e.el'
> --- a/lisp/mh-e/mh-e.el 2014-05-09 07:02:00 +0000
> +++ b/lisp/mh-e/mh-e.el 2014-09-30 05:06:42 +0000
> @@ -5,7 +5,7 @@
> ;; Author: Bill Wohler <wohler@newt.com>
> ;; Maintainer: Bill Wohler <wohler@newt.com>
> -;; Version: 8.5+bzr
> +;; Version: 8.6
> ;; Keywords: mail
> ;; This file is part of GNU Emacs.
> @@ -127,7 +127,7 @@
> ;; Try to keep variables local to a single file. Provide accessors if
> ;; variables are shared. Use this section as a last resort.
> -(defconst mh-version "8.5+bzr" "Version number of MH-E.")
> +(defconst mh-version "8.6" "Version number of MH-E.")
> ;; Variants
> _______________________________________________
> Emacs-diffs mailing list
> Emacs-diffs@gnu.org
> https://lists.gnu.org/mailman/listinfo/emacs-diffs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-09-30 15:56 ` [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522 Stefan Monnier
@ 2014-09-30 16:23 ` Bill Wohler
2014-09-30 16:53 ` Eli Zaretskii
2014-09-30 18:04 ` Stefan Monnier
0 siblings, 2 replies; 11+ messages in thread
From: Bill Wohler @ 2014-09-30 16:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan earlier suggested that I check in changes on the branch and merge
them into trunk. I thought I was doing what I was asked.
I did use bzr merge, but I added the -i flag to avoid pulling in other
people's changes.
$ bzr merge -i ../emacs-24/
$ bzr ci -m"Merge from emacs-24; up to r117522."
The man page for bzr merge -i says this:
To select only some changes to merge, use "merge -i", which will
prompt you to apply each diff hunk and file change, similar to
"shelve".
I had no indication that this would not include the merge information.
I'm sorry for the trouble I caused. Please feel free to revert and fix
as you see fit. I promise not to run a bzr command ever again :-).
Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Hi Bill,
>
> Don't do this. Your commit says you "merged" but the metadata says
> you didn't. You just duplicated the changes that you previously
> installed on emacs-24. So that'll just create spurious conflicts when
> we do merge the emacs-24 changes into trunk.
>
> You can merge things from emacs-24 to trunk if you want (and we always
> welcome people to do that, so that we don't have to), but you have to do
> it with a plain "bzr merge" or with "M-x bzrmerge" (from
> emacs/admin/bzrmerge.el), the latter being a more clever version of the
> former which knows about some of our coding conventions.
>
>
> Stefan
>
>
> >>>>> "Bill" == Bill Wohler <wohler@newt.com> writes:
>
> > ------------------------------------------------------------
> > revno: 117980
> > revision-id: wohler@newt.com-20140930050642-14nctsd0lavynqwi
> > parent: wohler@newt.com-20140930045810-hty0uyvr82ww5p3p
> > committer: Bill Wohler <wohler@newt.com>
> > branch nick: trunk
> > timestamp: Mon 2014-09-29 22:06:42 -0700
> > message:
> > Merge from emacs-24; up to r117522.
> > modified:
> > etc/MH-E-NEWS mhenews-20091113204419-o5vbwnq5f7feedwu-1489
> > etc/NEWS news-20100311060928-aoit31wvzf25yr1z-1
> > lisp/mh-e/ChangeLog changelog-20091113204419-o5vbwnq5f7feedwu-2547
> > lisp/mh-e/mh-comp.el mhcomp.el-20091113204419-o5vbwnq5f7feedwu-2532
> > lisp/mh-e/mh-e.el mhe.el-20091113204419-o5vbwnq5f7feedwu-2534
>
> > === modified file 'etc/MH-E-NEWS'
> > --- a/etc/MH-E-NEWS 2014-01-16 06:24:06 +0000
> > +++ b/etc/MH-E-NEWS 2014-09-30 05:06:42 +0000
> > @@ -3,6 +3,28 @@
> > Copyright (C) 2001-2014 Free Software Foundation, Inc.
> > See the end of the file for license conditions.
>
> > +* Changes in MH-E 8.6
> > +
> > +Version 8.6 fixes composition errors in nmh 1.6.
> > +
> > +** Bug Fixes in MH-E 8.6
> > +
> > +*** Add support for nmh 1.5
> > +
> > +A components file is now generated that works with nmh 1.5 (partially
> > +closes SF #468).
> > +
> > +*** Error if mh-x-face-file is nil
> > +
> > +Ensure that `mh-x-face-file' is a string before trying to use it
> > +(closes SF #474).
> > +
> > +*** MH-Folder buffer includes "scan: bad message list unseen"
> > +
> > +Fix this error (closes SF #471).
> > +
> > +\f
> > +
> > * Changes in MH-E 8.5
>
> > Version 8.5 fixes bugs when incorporating or forwarding mail.
>
> > === modified file 'etc/NEWS'
> > --- a/etc/NEWS 2014-09-29 18:14:08 +0000
> > +++ b/etc/NEWS 2014-09-30 05:06:42 +0000
> > @@ -918,7 +918,7 @@
>
> > *** Recognition and better indentation of continuations in array comprehensions.
>
> > -** MH-E has been updated to version 8.5 - see separate MH-E-NEWS file.
> > +** MH-E has been updated to version 8.6 - see separate MH-E-NEWS file.
>
> > ** Octave mode
>
>
> > === modified file 'lisp/mh-e/ChangeLog'
> > --- a/lisp/mh-e/ChangeLog 2014-05-09 07:02:00 +0000
> > +++ b/lisp/mh-e/ChangeLog 2014-09-30 05:06:42 +0000
> > @@ -1,3 +1,21 @@
> > +2014-09-30 Bill Wohler <wohler@newt.com>
> > +
> > + Release MH-E version 8.6.
> > +
> > + * mh-e.el (Version, mh-version): Update for release 8.6.
> > +
> > +2014-09-30 Mike Kupfer <m.kupfer@acm.org>
> > +
> > + * mh-comp.el (mh-insert-x-face): Ensure that mh-x-face-file is a
> > + string before trying to use it (closes SF #474).
> > + (mh-bare-components): New function to create a temporary initial
> > + components file; replaces mh-find-components. Improve the temp
> > + folder and file names as per a suggestion from Bill Wohler. Also
> > + address XEmacs compatibility issues: use mm-make-temp-file instead
> > + of make-temp-file, and only pass one argument to delete-directory.
> > + (mh-edit-again, mh-send-sub): Use mh-bare-components instead of
> > + mh-find-components (partially closes SF #468).
> > +
> > 2014-05-09 Glenn Morris <rgm@gnu.org>
>
> > * mh-e.el (mh-variants): Use file-accessible-directory-p.
>
> > === modified file 'lisp/mh-e/mh-comp.el'
> > --- a/lisp/mh-e/mh-comp.el 2014-01-01 07:43:34 +0000
> > +++ b/lisp/mh-e/mh-comp.el 2014-09-30 05:06:42 +0000
> > @@ -411,6 +411,7 @@
> > (interactive (list (mh-get-msg-num t)))
> > (let* ((from-folder mh-current-folder)
> > (config (current-window-configuration))
> > + (components-file (mh-bare-components))
> > (draft
> > (cond ((and mh-draft-folder (equal from-folder mh-draft-folder))
> > (pop-to-buffer (find-file-noselect (mh-msg-filename message))
> > @@ -467,7 +468,8 @@
> > ;; Text field, that's an easy case
> > (t
> > (mh-modify-header-field field value))))))
> > - (mh-components-to-list (mh-find-components)))
> > + (mh-components-to-list components-file))
> > + (delete-file components-file)
> > (goto-char (point-min))
> > (save-buffer)
> > (mh-compose-and-send-mail
> > @@ -885,22 +887,6 @@
> > (t
> > nil))))
>
> > -(defun mh-find-components ()
> > - "Return the path to the components file."
> > - (let (components)
> > - (cond
> > - ((file-exists-p
> > - (setq components
> > - (expand-file-name mh-comp-formfile mh-user-path)))
> > - components)
> > - ((file-exists-p
> > - (setq components
> > - (expand-file-name mh-comp-formfile mh-lib)))
> > - components)
> > - (t
> > - (error "Can't find %s in %s or %s"
> > - mh-comp-formfile mh-user-path mh-lib)))))
> > -
> > (defun mh-send-sub (to cc subject config)
> > "Do the real work of composing and sending a letter.
> > Expects the TO, CC, and SUBJECT fields as arguments.
> > @@ -910,8 +896,8 @@
> > (message "Composing a message...")
> > (let ((draft (mh-read-draft
> > "message"
> > - (mh-find-components)
> > - nil)))
> > + (mh-bare-components)
> > + t)))
> > (mh-insert-fields "To:" to "Subject:" subject "Cc:" cc)
> > (goto-char (point-max))
> > (mh-compose-and-send-mail draft "" folder msg-num
> > @@ -920,6 +906,29 @@
> > (mh-letter-mode-message)
> > (mh-letter-adjust-point))))
>
> > +(defun mh-bare-components ()
> > + "Generate a temporary, clean components file and return its path."
> > + ;; Let comp(1) create the skeleton for us. This is particularly
> > + ;; important with nmh-1.5, because its default "components" needs
> > + ;; some processing before it can be used. Unfortunately, comp(1)
> > + ;; doesn't have a -build option. So, to avoid the possibility of
> > + ;; clobbering an existing draft, create a temporary directory and
> > + ;; use it as the drafts folder. Then copy the skeleton to a regular
> > + ;; temp file, and return the regular temp file.
> > + (let (new
> > + (temp-folder (mm-make-temp-file
> > + (concat mh-user-path "draftfolder.") t)))
> > + (mh-exec-cmd "comp" "-nowhatnowproc"
> > + "-draftfolder" (format "+%s"
> > + (file-name-nondirectory temp-folder))
> > + (if (stringp mh-comp-formfile)
> > + (list "-form" mh-comp-formfile)))
> > + (setq new (mm-make-temp-file "comp."))
> > + (rename-file (concat temp-folder "/" "1") new t)
> > + (delete-file (concat temp-folder "/" ".mh_sequences"))
> > + (delete-directory temp-folder)
> > + new))
> > +
> > (defun mh-read-draft (use initial-contents delete-contents-file)
> > "Read draft file into a draft buffer and make that buffer the current one.
>
> > @@ -1069,7 +1078,8 @@
> > (defun mh-insert-x-face ()
> > "Append X-Face, Face or X-Image-URL field to header.
> > If the field already exists, this function does nothing."
> > - (when (and (file-exists-p mh-x-face-file)
> > + (when (and (stringp mh-x-face-file)
> > + (file-exists-p mh-x-face-file)
> > (file-readable-p mh-x-face-file))
> > (save-excursion
> > (unless (or (mh-position-on-field "X-Face")
>
> > === modified file 'lisp/mh-e/mh-e.el'
> > --- a/lisp/mh-e/mh-e.el 2014-05-09 07:02:00 +0000
> > +++ b/lisp/mh-e/mh-e.el 2014-09-30 05:06:42 +0000
> > @@ -5,7 +5,7 @@
>
> > ;; Author: Bill Wohler <wohler@newt.com>
> > ;; Maintainer: Bill Wohler <wohler@newt.com>
> > -;; Version: 8.5+bzr
> > +;; Version: 8.6
> > ;; Keywords: mail
>
> > ;; This file is part of GNU Emacs.
> > @@ -127,7 +127,7 @@
> > ;; Try to keep variables local to a single file. Provide accessors if
> > ;; variables are shared. Use this section as a last resort.
>
> > -(defconst mh-version "8.5+bzr" "Version number of MH-E.")
> > +(defconst mh-version "8.6" "Version number of MH-E.")
>
> > ;; Variants
>
>
> > _______________________________________________
> > Emacs-diffs mailing list
> > Emacs-diffs@gnu.org
> > https://lists.gnu.org/mailman/listinfo/emacs-diffs
--
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-09-30 16:23 ` Bill Wohler
@ 2014-09-30 16:53 ` Eli Zaretskii
2014-09-30 18:04 ` Stefan Monnier
1 sibling, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2014-09-30 16:53 UTC (permalink / raw)
To: Bill Wohler; +Cc: emacs-devel
> From: Bill Wohler <wohler@newt.com>
> Date: Tue, 30 Sep 2014 09:23:33 -0700
> Cc: emacs-devel@gnu.org
>
> I did use bzr merge, but I added the -i flag to avoid pulling in other
> people's changes.
>
> $ bzr merge -i ../emacs-24/
> $ bzr ci -m"Merge from emacs-24; up to r117522."
>
> The man page for bzr merge -i says this:
>
> To select only some changes to merge, use "merge -i", which will
> prompt you to apply each diff hunk and file change, similar to
> "shelve".
>
> I had no indication that this would not include the merge information.
Whenever you merge only some of the commits, you are actually
cherry-picking. And cherry-picking is not tracked in the history DAG
of the VCS, at least not in bzr (and not in git, either).
You should merge without the -i switch, and without manually selecting
revisions to merge. Then the meta-data will record all the revisions
you merged. As Stefan says, using "M-x bzrmerge" is an easy way of
doing TRT in these situations (it will also pay attention to revisions
that were marked as "don't merge to trunk").
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-09-30 16:23 ` Bill Wohler
2014-09-30 16:53 ` Eli Zaretskii
@ 2014-09-30 18:04 ` Stefan Monnier
2014-10-01 2:52 ` Stephen J. Turnbull
1 sibling, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2014-09-30 18:04 UTC (permalink / raw)
To: emacs-devel
> I had no indication that this would not include the merge information.
Indeed, "bzr merge --help" is carefully silent about this side-effect :-(
Sadly, the only DVCS which knew how to keep track of partial (aka
cherry-picked) merges were DaRCS and Arch, AFAIK.
> I'm sorry for the trouble I caused. Please feel free to revert and fix
> as you see fit.
No, we'll just deal with the spurious conflicts when we do the merge.
> I promise not to run a bzr command ever again :-).
FWIW, Git suffers from the same problem, AFAIK. Tho maybe Git has found
a clever way to handle them OK in practice, even though it doesn't
actually keep track of them either (along the lines of what it does for
file renames).
Stefan
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Hi Bill,
>>
>> Don't do this. Your commit says you "merged" but the metadata says
>> you didn't. You just duplicated the changes that you previously
>> installed on emacs-24. So that'll just create spurious conflicts when
>> we do merge the emacs-24 changes into trunk.
>>
>> You can merge things from emacs-24 to trunk if you want (and we always
>> welcome people to do that, so that we don't have to), but you have to do
>> it with a plain "bzr merge" or with "M-x bzrmerge" (from
>> emacs/admin/bzrmerge.el), the latter being a more clever version of the
>> former which knows about some of our coding conventions.
>>
>>
>> Stefan
>>
>>
>> >>>>> "Bill" == Bill Wohler <wohler@newt.com> writes:
>>
>> > ------------------------------------------------------------
>> > revno: 117980
>> > revision-id: wohler@newt.com-20140930050642-14nctsd0lavynqwi
>> > parent: wohler@newt.com-20140930045810-hty0uyvr82ww5p3p
>> > committer: Bill Wohler <wohler@newt.com>
>> > branch nick: trunk
>> > timestamp: Mon 2014-09-29 22:06:42 -0700
>> > message:
>> > Merge from emacs-24; up to r117522.
>> > modified:
>> > etc/MH-E-NEWS mhenews-20091113204419-o5vbwnq5f7feedwu-1489
>> > etc/NEWS news-20100311060928-aoit31wvzf25yr1z-1
>> > lisp/mh-e/ChangeLog changelog-20091113204419-o5vbwnq5f7feedwu-2547
>> > lisp/mh-e/mh-comp.el mhcomp.el-20091113204419-o5vbwnq5f7feedwu-2532
>> > lisp/mh-e/mh-e.el mhe.el-20091113204419-o5vbwnq5f7feedwu-2534
>>
>> > === modified file 'etc/MH-E-NEWS'
>> > --- a/etc/MH-E-NEWS 2014-01-16 06:24:06 +0000
>> > +++ b/etc/MH-E-NEWS 2014-09-30 05:06:42 +0000
>> > @@ -3,6 +3,28 @@
>> > Copyright (C) 2001-2014 Free Software Foundation, Inc.
>> > See the end of the file for license conditions.
>>
>> > +* Changes in MH-E 8.6
>> > +
>> > +Version 8.6 fixes composition errors in nmh 1.6.
>> > +
>> > +** Bug Fixes in MH-E 8.6
>> > +
>> > +*** Add support for nmh 1.5
>> > +
>> > +A components file is now generated that works with nmh 1.5 (partially
>> > +closes SF #468).
>> > +
>> > +*** Error if mh-x-face-file is nil
>> > +
>> > +Ensure that `mh-x-face-file' is a string before trying to use it
>> > +(closes SF #474).
>> > +
>> > +*** MH-Folder buffer includes "scan: bad message list unseen"
>> > +
>> > +Fix this error (closes SF #471).
>> > +
>> > +\f
>> > +
>> > * Changes in MH-E 8.5
>>
>> > Version 8.5 fixes bugs when incorporating or forwarding mail.
>>
>> > === modified file 'etc/NEWS'
>> > --- a/etc/NEWS 2014-09-29 18:14:08 +0000
>> > +++ b/etc/NEWS 2014-09-30 05:06:42 +0000
>> > @@ -918,7 +918,7 @@
>>
>> > *** Recognition and better indentation of continuations in array comprehensions.
>>
>> > -** MH-E has been updated to version 8.5 - see separate MH-E-NEWS file.
>> > +** MH-E has been updated to version 8.6 - see separate MH-E-NEWS file.
>>
>> > ** Octave mode
>>
>>
>> > === modified file 'lisp/mh-e/ChangeLog'
>> > --- a/lisp/mh-e/ChangeLog 2014-05-09 07:02:00 +0000
>> > +++ b/lisp/mh-e/ChangeLog 2014-09-30 05:06:42 +0000
>> > @@ -1,3 +1,21 @@
>> > +2014-09-30 Bill Wohler <wohler@newt.com>
>> > +
>> > + Release MH-E version 8.6.
>> > +
>> > + * mh-e.el (Version, mh-version): Update for release 8.6.
>> > +
>> > +2014-09-30 Mike Kupfer <m.kupfer@acm.org>
>> > +
>> > + * mh-comp.el (mh-insert-x-face): Ensure that mh-x-face-file is a
>> > + string before trying to use it (closes SF #474).
>> > + (mh-bare-components): New function to create a temporary initial
>> > + components file; replaces mh-find-components. Improve the temp
>> > + folder and file names as per a suggestion from Bill Wohler. Also
>> > + address XEmacs compatibility issues: use mm-make-temp-file instead
>> > + of make-temp-file, and only pass one argument to delete-directory.
>> > + (mh-edit-again, mh-send-sub): Use mh-bare-components instead of
>> > + mh-find-components (partially closes SF #468).
>> > +
>> > 2014-05-09 Glenn Morris <rgm@gnu.org>
>>
>> > * mh-e.el (mh-variants): Use file-accessible-directory-p.
>>
>> > === modified file 'lisp/mh-e/mh-comp.el'
>> > --- a/lisp/mh-e/mh-comp.el 2014-01-01 07:43:34 +0000
>> > +++ b/lisp/mh-e/mh-comp.el 2014-09-30 05:06:42 +0000
>> > @@ -411,6 +411,7 @@
>> > (interactive (list (mh-get-msg-num t)))
>> > (let* ((from-folder mh-current-folder)
>> > (config (current-window-configuration))
>> > + (components-file (mh-bare-components))
>> > (draft
>> > (cond ((and mh-draft-folder (equal from-folder mh-draft-folder))
>> > (pop-to-buffer (find-file-noselect (mh-msg-filename message))
>> > @@ -467,7 +468,8 @@
>> > ;; Text field, that's an easy case
>> > (t
>> > (mh-modify-header-field field value))))))
>> > - (mh-components-to-list (mh-find-components)))
>> > + (mh-components-to-list components-file))
>> > + (delete-file components-file)
>> > (goto-char (point-min))
>> > (save-buffer)
>> > (mh-compose-and-send-mail
>> > @@ -885,22 +887,6 @@
>> > (t
>> > nil))))
>>
>> > -(defun mh-find-components ()
>> > - "Return the path to the components file."
>> > - (let (components)
>> > - (cond
>> > - ((file-exists-p
>> > - (setq components
>> > - (expand-file-name mh-comp-formfile mh-user-path)))
>> > - components)
>> > - ((file-exists-p
>> > - (setq components
>> > - (expand-file-name mh-comp-formfile mh-lib)))
>> > - components)
>> > - (t
>> > - (error "Can't find %s in %s or %s"
>> > - mh-comp-formfile mh-user-path mh-lib)))))
>> > -
>> > (defun mh-send-sub (to cc subject config)
>> > "Do the real work of composing and sending a letter.
>> > Expects the TO, CC, and SUBJECT fields as arguments.
>> > @@ -910,8 +896,8 @@
>> > (message "Composing a message...")
>> > (let ((draft (mh-read-draft
>> > "message"
>> > - (mh-find-components)
>> > - nil)))
>> > + (mh-bare-components)
>> > + t)))
>> > (mh-insert-fields "To:" to "Subject:" subject "Cc:" cc)
>> > (goto-char (point-max))
>> > (mh-compose-and-send-mail draft "" folder msg-num
>> > @@ -920,6 +906,29 @@
>> > (mh-letter-mode-message)
>> > (mh-letter-adjust-point))))
>>
>> > +(defun mh-bare-components ()
>> > + "Generate a temporary, clean components file and return its path."
>> > + ;; Let comp(1) create the skeleton for us. This is particularly
>> > + ;; important with nmh-1.5, because its default "components" needs
>> > + ;; some processing before it can be used. Unfortunately, comp(1)
>> > + ;; doesn't have a -build option. So, to avoid the possibility of
>> > + ;; clobbering an existing draft, create a temporary directory and
>> > + ;; use it as the drafts folder. Then copy the skeleton to a regular
>> > + ;; temp file, and return the regular temp file.
>> > + (let (new
>> > + (temp-folder (mm-make-temp-file
>> > + (concat mh-user-path "draftfolder.") t)))
>> > + (mh-exec-cmd "comp" "-nowhatnowproc"
>> > + "-draftfolder" (format "+%s"
>> > + (file-name-nondirectory temp-folder))
>> > + (if (stringp mh-comp-formfile)
>> > + (list "-form" mh-comp-formfile)))
>> > + (setq new (mm-make-temp-file "comp."))
>> > + (rename-file (concat temp-folder "/" "1") new t)
>> > + (delete-file (concat temp-folder "/" ".mh_sequences"))
>> > + (delete-directory temp-folder)
>> > + new))
>> > +
>> > (defun mh-read-draft (use initial-contents delete-contents-file)
>> > "Read draft file into a draft buffer and make that buffer the current one.
>>
>> > @@ -1069,7 +1078,8 @@
>> > (defun mh-insert-x-face ()
>> > "Append X-Face, Face or X-Image-URL field to header.
>> > If the field already exists, this function does nothing."
>> > - (when (and (file-exists-p mh-x-face-file)
>> > + (when (and (stringp mh-x-face-file)
>> > + (file-exists-p mh-x-face-file)
>> > (file-readable-p mh-x-face-file))
>> > (save-excursion
>> > (unless (or (mh-position-on-field "X-Face")
>>
>> > === modified file 'lisp/mh-e/mh-e.el'
>> > --- a/lisp/mh-e/mh-e.el 2014-05-09 07:02:00 +0000
>> > +++ b/lisp/mh-e/mh-e.el 2014-09-30 05:06:42 +0000
>> > @@ -5,7 +5,7 @@
>>
>> > ;; Author: Bill Wohler <wohler@newt.com>
>> > ;; Maintainer: Bill Wohler <wohler@newt.com>
>> > -;; Version: 8.5+bzr
>> > +;; Version: 8.6
>> > ;; Keywords: mail
>>
>> > ;; This file is part of GNU Emacs.
>> > @@ -127,7 +127,7 @@
>> > ;; Try to keep variables local to a single file. Provide accessors if
>> > ;; variables are shared. Use this section as a last resort.
>>
>> > -(defconst mh-version "8.5+bzr" "Version number of MH-E.")
>> > +(defconst mh-version "8.6" "Version number of MH-E.")
>>
>> > ;; Variants
>>
>>
>> > _______________________________________________
>> > Emacs-diffs mailing list
>> > Emacs-diffs@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/emacs-diffs
> --
> Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
> http://www.newt.com/wohler/
> GnuPG ID:610BD9AD
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-09-30 18:04 ` Stefan Monnier
@ 2014-10-01 2:52 ` Stephen J. Turnbull
2014-10-01 14:44 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: Stephen J. Turnbull @ 2014-10-01 2:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier writes:
> Sadly, the only DVCS which knew how to keep track of partial (aka
> cherry-picked) merges were DaRCS and Arch, AFAIK.
But in those DVCSes you lose the DAG, and gain exponential behavior
for your trouble. (Speaking of Darcs in the past tense isn't very
accurate, either, although at the moment they're in maintenance mode.)
Tom Lord's revc (aka Arch v3) was showing theoretical promise in this
direction: he based object storage (Arch's revision archive) on git's,
but also was able to manipulate changes (revid pairs). I'm not sure
if he planned to add token replacement and similar Darcs-y features.
> FWIW, Git suffers from the same problem, AFAIK. Tho maybe Git has found
> a clever way to handle them OK in practice, even though it doesn't
> actually keep track of them either (along the lines of what it does for
> file renames).
No, there's no trick in git for this. It's just that the git
community has a culture of rebasing that is much more tolerant of loss
of actual history (as seen by the developer in a private workspace) as
long as the notional history (post rebase and pushed to public) makes
sense to the community. In this view, a cherry-pick is sort of viewed
as a "reinvention" of the patch, even though it's actually a copy.
It's possible to do the equivalent of "bzr merge -i" in git using
filter-branch, but it's somewhat complex and there's no built-in
command for it. git just counts on the locality of commits in a
branch (ie, commits different branches touch the same code
infrequently) when doing a three-way merge. I don't think a
patch-tracking VCS like Darcs would do a better job, though -- you'd
end up with a conflict in that case too.
For future reference:
Git has an option to cherry-pick which inserts the revision[1]
cherry-picked in the commit log automatically. I believe that changed
from default on to default off years ago, though. So I guess it
wasn't considered as useful as saving bytes (and lines in log message
displays). As Eli points out, it's *not* recorded in the DAG, maybe
that's why.
Footnotes:
[1] Indicating the change relative to the parent, not the state of
the tree.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-10-01 2:52 ` Stephen J. Turnbull
@ 2014-10-01 14:44 ` Eli Zaretskii
2014-10-01 15:22 ` Yuri Khan
2014-10-01 17:44 ` Stefan Monnier
0 siblings, 2 replies; 11+ messages in thread
From: Eli Zaretskii @ 2014-10-01 14:44 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: monnier, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 01 Oct 2014 11:52:58 +0900
> Cc: emacs-devel@gnu.org
>
> Stefan Monnier writes:
>
> > Sadly, the only DVCS which knew how to keep track of partial (aka
> > cherry-picked) merges were DaRCS and Arch, AFAIK.
>
> But in those DVCSes you lose the DAG, and gain exponential behavior
> for your trouble. (Speaking of Darcs in the past tense isn't very
> accurate, either, although at the moment they're in maintenance mode.)
>
> Tom Lord's revc (aka Arch v3) was showing theoretical promise in this
> direction: he based object storage (Arch's revision archive) on git's,
> but also was able to manipulate changes (revid pairs). I'm not sure
> if he planned to add token replacement and similar Darcs-y features.
It strikes me that the VCS could merge all the commits up to the one I
want to cherry-pick, and then revert all the rest. But I guess there
are complications with this strategy, or else it would have been
implemented already.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-10-01 14:44 ` Eli Zaretskii
@ 2014-10-01 15:22 ` Yuri Khan
2014-10-01 15:45 ` Eli Zaretskii
2014-10-01 17:44 ` Stefan Monnier
1 sibling, 1 reply; 11+ messages in thread
From: Yuri Khan @ 2014-10-01 15:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen J. Turnbull, Stefan Monnier, Emacs developers
On Wed, Oct 1, 2014 at 9:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> It strikes me that the VCS could merge all the commits up to the one I
> want to cherry-pick, and then revert all the rest. But I guess there
> are complications with this strategy, or else it would have been
> implemented already.
* A revert is the same thing as a cherry-pick, just with an opposite
sign. Would you really want to fix a missing link of a cherry-picked
commit to its original by introducing a few thousand reverts, all with
missing links to the original commits they revert?
* Imagine a mergy graph on the branch being cherry-picked from. How do
you revert that mergy clump? What if there are merges from that into
the current branch?
---o---o---o---o---o---o A
\ /
o---o---o---o B
\ /
o---o
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-10-01 15:22 ` Yuri Khan
@ 2014-10-01 15:45 ` Eli Zaretskii
2014-10-01 15:49 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2014-10-01 15:45 UTC (permalink / raw)
To: Yuri Khan; +Cc: stephen, monnier, emacs-devel
> Date: Wed, 1 Oct 2014 22:22:25 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
> Emacs developers <emacs-devel@gnu.org>
>
> * A revert is the same thing as a cherry-pick, just with an opposite
> sign. Would you really want to fix a missing link of a cherry-picked
> commit to its original by introducing a few thousand reverts, all with
> missing links to the original commits they revert?
>
> * Imagine a mergy graph on the branch being cherry-picked from. How do
> you revert that mergy clump? What if there are merges from that into
> the current branch?
>
> ---o---o---o---o---o---o A
> \ /
> o---o---o---o B
> \ /
> o---o
Well, figure it out, and you get my thumbs-up!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-10-01 15:45 ` Eli Zaretskii
@ 2014-10-01 15:49 ` Eli Zaretskii
2014-10-02 1:48 ` Stephen J. Turnbull
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2014-10-01 15:49 UTC (permalink / raw)
To: yuri.v.khan; +Cc: stephen, monnier, emacs-devel
> Date: Wed, 01 Oct 2014 18:45:14 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: stephen@xemacs.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> > * Imagine a mergy graph on the branch being cherry-picked from. How do
> > you revert that mergy clump? What if there are merges from that into
> > the current branch?
> >
> > ---o---o---o---o---o---o A
> > \ /
> > o---o---o---o B
> > \ /
> > o---o
>
> Well, figure it out, and you get my thumbs-up!
Btw, it's a bit ironic that while there's a lot of pressure to rebase
branches instead of merging them, when these issues are discussed,
suddenly all kind of complex DAGs pop up all over the place. If
rebasing is the word of the day, then you will almost never see such
DAGs.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-10-01 14:44 ` Eli Zaretskii
2014-10-01 15:22 ` Yuri Khan
@ 2014-10-01 17:44 ` Stefan Monnier
1 sibling, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2014-10-01 17:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen J. Turnbull, emacs-devel
> It strikes me that the VCS could merge all the commits up to the one I
> want to cherry-pick, and then revert all the rest. But I guess there
> are complications with this strategy, or else it would have been
> implemented already.
The problem is not only how to perform the merge, but how to *remember* it.
I.e. so that next time you merge from emacs-24, it will know that it
needs to merge all the changes except for the ones that were already
cherry-picked.
BTW, It gets interesting pretty quickly:
- Say I have a local branch `Stef'.
- `Stef' generally tracks `trunk'.
- I cherry-pick into `Stef' revision 57 and 93 from `emacs-24'.
- Someone merges `emacs-24' into `trunk'. I.e. commit 187 from `trunk'
is a "merge commit" that merges all changes from `emacs-24' upto
revision 98.
- Now I want to update `Stef' by merging the latest `trunk' (which is
now at revision 192) into it. Should commit 187 be merged as well?
The answer is "yes but no":
- yes, because it brings changes from `emacs-24' which we don't yet have.
- no, because it would bring changes from `emacs-24' which we already applied.
So it could try to "take revision 192, try to reverse the changes from
revisions 57 and 93" and then apply the result to `Stef', but as you
can see.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522.
2014-10-01 15:49 ` Eli Zaretskii
@ 2014-10-02 1:48 ` Stephen J. Turnbull
0 siblings, 0 replies; 11+ messages in thread
From: Stephen J. Turnbull @ 2014-10-02 1:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, monnier, yuri.v.khan
Eli Zaretskii writes:
> > Date: Wed, 01 Oct 2014 18:45:14 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: stephen@xemacs.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >
> > > * Imagine a mergy graph on the branch being cherry-picked from. How do
> > > you revert that mergy clump? What if there are merges from that into
> > > the current branch?
> > >
> > > ---o---o---o---o---o---o A
> > > \ /
> > > o---o---o---o B
> > > \ /
> > > o---o
> >
> > Well, figure it out, and you get my thumbs-up!
>
> Btw, it's a bit ironic that while there's a lot of pressure to rebase
> branches instead of merging them, when these issues are discussed,
> suddenly all kind of complex DAGs pop up all over the place. If
> rebasing is the word of the day, then you will almost never see such
> DAGs.
I don't see the irony yet (the people who push rebasing are not
necessarily the same people who are explaining the technology), but
that's probably because I explain this as a difference of culture in
the git community vs. the Bazaar community.[1] Same point, different
point of view.
The real problem as Stefan points out is that in these VCSes the
source of a cherry-pick is *not* part of the formal metadata of the
new commit (git cherry-pick -x is a typical *in*formal way to record
the information).
Git does have a (rarely used AFAIK) concept of "grafts", which are an
out of band record of equivalent (as revisions) commits. This doesn't
work terribly well (if the commits point to different trees, the
relation is actually asymmetric), and is mostly useful in cases where
filter-branch is used to remove some commits near the root of the DAG,
but does not affect the trees (ie, it just reparents downstream
commits to earlier ancestors).
What we want here is a way to equivalence changes. The obvious
representation of a change would be the corresponding SHA1 pair.
(However, as Darcs points out, there are useful "patches" that have
effects that cannot be reproduced using diff and patch (and the
token-replace patch is actually implemented in Darcs). Whether those
patch types are "useful enough" probably depends on the language, the
project, and the programmers.)
Then the question would be how to use that information later. Git
developers evidently don't have an idea or have an idea but decided it
wasn't terribly useful compared to the alternative (merge when you
care about history-in-place, rebase when you don't, where "you" refers
to a project-wide consensus or it all falls down).
Footnotes:
[1] Speaking of irony, has anybody else noticed the irony of calling
the bzr development process "Bazaar"?
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-10-02 1:48 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <E1XYpeB-0002D6-5f@vcs.savannah.gnu.org>
2014-09-30 15:56 ` [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522 Stefan Monnier
2014-09-30 16:23 ` Bill Wohler
2014-09-30 16:53 ` Eli Zaretskii
2014-09-30 18:04 ` Stefan Monnier
2014-10-01 2:52 ` Stephen J. Turnbull
2014-10-01 14:44 ` Eli Zaretskii
2014-10-01 15:22 ` Yuri Khan
2014-10-01 15:45 ` Eli Zaretskii
2014-10-01 15:49 ` Eli Zaretskii
2014-10-02 1:48 ` Stephen J. Turnbull
2014-10-01 17:44 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).