From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Merging emacs-23 into trunk
Date: Thu, 11 Nov 2010 11:52:38 +0900 [thread overview]
Message-ID: <87vd44efm1.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <8362w5f0lx.fsf@gnu.org>
Eli Zaretskii writes:
> > Actually, I'm not cherry-picking
>
> I think you are. From the docs of "bzr merge":
You of all people whould know better than to trust the Bazaar docs!
There are two different, though closely related, definitions, of
"cherrypicking" in practice.
Definition 1, "merging individual revisions, or a subset of available
revisions", is the one used by the Bazaar documents and the Bazaar
developers.
Definition 2, which is the one Stefan is implicitly using, is "merging
individual revisions, or a subset of available revisions, *forcing the
VCS to forget* associations between changes and revisions." (My
wording is a bit awkward because this subtlety is almost never made
explicit; this is the first time I've tried.)
In the DAG-oriented VCSes (git, Mercurial, Bazaar), there is no
practical difference because once you ask for an out-of-order patch
application the DAG no longer applies simplistically; in particular,
you can't compute the ancestor for a three-way merge. By design they
forget. ("git filter-branch" and "git rebase --interactive" are hacks
allowing you to provide the necessary information out-of-DAG.)
GNU Arch (and Darcs) know which changes have been applied to the tree;
there is no presumption that they are applied in history-determined
subsets. (The difference between Arch and Darcs is that Arch required
the user to try applying and then resolve conflicts at the changeset
level, one after another; Darcs is smart enough to compute where
conflicts will occur, and it then rearranges hunk order to maximize
automatic application before asking the user to resolve conflicts.)
Stefan, who is familiar with both GNU Arch and Darcs, I believe,
correctly perceives Bazaar behavior as a huge regression vs. Arch in
this respect.
next prev parent reply other threads:[~2010-11-11 2:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 21:30 Merging emacs-23 into trunk Stefan Monnier
2010-11-10 4:34 ` Glenn Morris
2010-11-10 5:44 ` Stephen J. Turnbull
2010-11-10 11:59 ` Eli Zaretskii
2010-11-11 2:28 ` Stephen J. Turnbull
2010-11-11 6:32 ` Eli Zaretskii
2010-11-11 8:39 ` Stephen J. Turnbull
2010-11-11 9:11 ` Eli Zaretskii
2010-11-11 12:29 ` Stephen J. Turnbull
2010-11-10 9:01 ` Andreas Schwab
2010-11-10 15:38 ` Stefan Monnier
2010-11-10 17:28 ` Glenn Morris
2010-11-10 20:42 ` Glenn Morris
2010-11-10 22:30 ` Chad Brown
2010-11-11 4:02 ` Eli Zaretskii
2010-11-11 5:09 ` Kenichi Handa
2010-11-11 19:55 ` Glenn Morris
2010-11-11 20:01 ` Lennart Borgman
2010-11-11 20:23 ` Óscar Fuentes
2010-11-11 20:49 ` Eli Zaretskii
2010-11-10 12:03 ` Eli Zaretskii
2010-11-10 15:46 ` Stefan Monnier
2010-11-10 17:21 ` Eli Zaretskii
2010-11-10 19:03 ` Stefan Monnier
2010-11-10 19:19 ` Eli Zaretskii
2010-11-10 19:36 ` Óscar Fuentes
2010-11-11 6:26 ` Eli Zaretskii
2010-11-11 17:13 ` Óscar Fuentes
2010-11-11 2:52 ` Stephen J. Turnbull [this message]
2010-11-11 6:38 ` Eli Zaretskii
2010-11-10 19:32 ` Óscar Fuentes
2010-11-11 19:57 ` Stefan Monnier
2010-11-11 20:20 ` Óscar Fuentes
[not found] ` <jwvd3qbo3z1.fsf-monnier+emacs@gnu.org>
2010-11-12 16:51 ` Óscar Fuentes
2010-11-12 20:41 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vd44efm1.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.