* Merging emacs-23 into trunk @ 2010-11-09 21:30 Stefan Monnier 2010-11-10 4:34 ` Glenn Morris 2010-11-10 12:03 ` Eli Zaretskii 0 siblings, 2 replies; 35+ messages in thread From: Stefan Monnier @ 2010-11-09 21:30 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 824 bytes --] FWIW, here's the code I've used to merge the emacs-23 branch into the trunk. It presumes that the commits I don't want to include have the keyword "backport" or "merge" in it, so please make sure you include such keywords in your "not to be merged" commits in the future. It's pretty rough, and is scaringly slow (to some extent because of bzr's braindead lack of support for merging into a tree that's not clean). But that merge seemed like a good opportunity, since it had many backports and a naive merge generated tons of conflicts (a large part of them due to "bump version"). BTW, thanks Chong for committing the "bump version" separately from any real change, so I could just skip that patch rather than try and come up with some clever way to recognize and auto-resolve the resulting conflicts. Stefan [-- Attachment #2: bzrmerge.el --] [-- Type: application/emacs-lisp, Size: 13220 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 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 ` (2 more replies) 2010-11-10 12:03 ` Eli Zaretskii 1 sibling, 3 replies; 35+ messages in thread From: Glenn Morris @ 2010-11-10 4:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Can you make it just skip merging configure altogether? It's pointless to merge this generated file between branches, and it creates merge diffs that are largely noise (eg most recent merge of emacs23 to trunk). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 4:34 ` Glenn Morris @ 2010-11-10 5:44 ` Stephen J. Turnbull 2010-11-10 11:59 ` Eli Zaretskii 2010-11-10 9:01 ` Andreas Schwab 2010-11-10 15:38 ` Stefan Monnier 2 siblings, 1 reply; 35+ messages in thread From: Stephen J. Turnbull @ 2010-11-10 5:44 UTC (permalink / raw) To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel Glenn Morris writes: > Can you make it just skip merging configure altogether? Not really. That's inherent in the philosophy of atomic commits and DAG-based merging. A very dedicated maintainer with nothing better to do might be able to make it appear like it isn't being merged by maintaining a separate "no-configure" branch in which configure has been "bzr rm'd", then merging Branch-A --> no-configure --> Branch-B. I suspect that the Branch-A --> no-configure merge will throw a remove/modify conflict every time, but even if so this should be easy to automate with a "bzr replay-recorded-resolution" command (a la git's "rerere" command, if you know about that). If there isn't one already, the Bazaar team might be willing to cons one up. Similar considerations would apply on the no-configure --> Branch-B side. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 5:44 ` Stephen J. Turnbull @ 2010-11-10 11:59 ` Eli Zaretskii 2010-11-11 2:28 ` Stephen J. Turnbull 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-10 11:59 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: monnier, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Wed, 10 Nov 2010 14:44:49 +0900 > Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org > > Glenn Morris writes: > > > Can you make it just skip merging configure altogether? > > Not really. That's inherent in the philosophy of atomic commits and > DAG-based merging. I don't follow. Do you have in mind a revision where configure was committed together with other files? If so, I understand. But if it was committed alone, what is the issue with atomic commits? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 11:59 ` Eli Zaretskii @ 2010-11-11 2:28 ` Stephen J. Turnbull 2010-11-11 6:32 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Stephen J. Turnbull @ 2010-11-11 2:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli Zaretskii writes: > > From: "Stephen J. Turnbull" <stephen@xemacs.org> > > Date: Wed, 10 Nov 2010 14:44:49 +0900 > > Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org > > > > Glenn Morris writes: > > > > > Can you make it just skip merging configure altogether? > > > > Not really. That's inherent in the philosophy of atomic commits and > > DAG-based merging. > > I don't follow. Do you have in mind a revision where configure was > committed together with other files? If so, I understand. But if it > was committed alone, what is the issue with atomic commits? The words "philosophy" and "and" in my statement are crucial. Of course we've learned how to split an atom. But then it's not an atom any more. Similarly, if you are going to commit changes to a generated file, then it should be committed with the source changes that generate them. The DAG-based merging helps to enforce this because there's no way that the VCS can determine that these changes are related via syntactic analysis, and humans won't always get it right. So DAG- based merging takes branch history as the proxy for relatedness. That's why workflows are so important. If you want a "better" notion of relatedness, use Darcs, which is designed to be more or less workflow-free (but in practice doesn't achieve that yet). The fact that Bazaar doesn't handle the situation very well is quite apart from the design philosophy. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 2:28 ` Stephen J. Turnbull @ 2010-11-11 6:32 ` Eli Zaretskii 2010-11-11 8:39 ` Stephen J. Turnbull 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-11 6:32 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: monnier, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: monnier@IRO.UMontreal.CA, > emacs-devel@gnu.org > Date: Thu, 11 Nov 2010 11:28:39 +0900 > > > > > Can you make it just skip merging configure altogether? > > > > > > Not really. That's inherent in the philosophy of atomic commits and > > > DAG-based merging. > > > > I don't follow. Do you have in mind a revision where configure was > > committed together with other files? If so, I understand. But if it > > was committed alone, what is the issue with atomic commits? > > The words "philosophy" and "and" in my statement are crucial. Of > course we've learned how to split an atom. But then it's not an atom > any more. Similarly, if you are going to commit changes to a > generated file, then it should be committed with the source changes > that generate them. If committing configure alone is all we need to avoid the problem, we could decide to do that, philosophical and atom-splitting issues notwithstanding. Alternatively, "bzr revert configure" before committing the merges should also do. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 6:32 ` Eli Zaretskii @ 2010-11-11 8:39 ` Stephen J. Turnbull 2010-11-11 9:11 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Stephen J. Turnbull @ 2010-11-11 8:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli Zaretskii writes: > If committing configure alone is all we need to avoid the problem, we > could decide to do that, philosophical and atom-splitting issues > notwithstanding. No, I'm saying that the design of bzr doesn't permit that. > Alternatively, "bzr revert configure" before committing the merges > should also do. As long as the Makefile knows to update configure, you're OK until somebody with a different version of autoconf reports a bug. Or somebody with *no* autoconf decides to build, and gets stopped before they get started even though they've got a perfectly good configure. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 8:39 ` Stephen J. Turnbull @ 2010-11-11 9:11 ` Eli Zaretskii 2010-11-11 12:29 ` Stephen J. Turnbull 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-11 9:11 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: monnier, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: monnier@IRO.UMontreal.CA, > emacs-devel@gnu.org > Date: Thu, 11 Nov 2010 17:39:05 +0900 > > Eli Zaretskii writes: > > > If committing configure alone is all we need to avoid the problem, we > > could decide to do that, philosophical and atom-splitting issues > > notwithstanding. > > No, I'm saying that the design of bzr doesn't permit that. ??? Which part of design of bzr won't permit me doing the following? bzr ci configure.in ChangeLog bzr ci configure > As long as the Makefile knows to update configure, you're OK until > somebody with a different version of autoconf reports a bug. Or > somebody with *no* autoconf decides to build, and gets stopped before > they get started even though they've got a perfectly good configure. The issue of whether to have configure in the repository is a separate one. If the decision is not to track it, then, of course, all of the above is not relevant. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 9:11 ` Eli Zaretskii @ 2010-11-11 12:29 ` Stephen J. Turnbull 0 siblings, 0 replies; 35+ messages in thread From: Stephen J. Turnbull @ 2010-11-11 12:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli Zaretskii writes: > ??? Which part of design of bzr won't permit me doing the > following? Eli, I have no idea how you could possibly think that's an appropriate question at this point in the thread (and the same goes for several of your following comments), so I'm going to quit while I'm ahead. However, in considering how to reply, I did come up with one suggestion possibly worthy of consideration. > The issue of whether to have configure in the repository is a separate > one. If the decision is not to track it, then, of course, all of the > above is not relevant. Obviously, configure *is* in the repo. Then you either do something to prevent the problems I described, or sooner or later they arise. The obvious thing to do is to run autoconf, then commit configure along with configure.in. To keep Glenn happy, maybe the Bazaar guys can come up with a plugin or a patch that allows you to configure files that should never be diffed unless you ask for it (like binaries, you just get a stanza in the diff that says the files differ but the diff itself is omitted because the file appears in .diffignore or diff.ignore= in .bzr/config). That likely won't be too hard, because they have to do something more complex to avoid spewing binary garbage, anyway. So there is some place where bzr is going, "oh, let's not display the diff of this file" and suppressing either the diff operation itself or the output. Quite likely it's a couple of lines to change to add this feature. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 4:34 ` Glenn Morris 2010-11-10 5:44 ` Stephen J. Turnbull @ 2010-11-10 9:01 ` Andreas Schwab 2010-11-10 15:38 ` Stefan Monnier 2 siblings, 0 replies; 35+ messages in thread From: Andreas Schwab @ 2010-11-10 9:01 UTC (permalink / raw) To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel Glenn Morris <rgm@gnu.org> writes: > Can you make it just skip merging configure altogether? It should be regenerated whenever its sources changed (as long as we keep it versioned). Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 4:34 ` Glenn Morris 2010-11-10 5:44 ` Stephen J. Turnbull 2010-11-10 9:01 ` Andreas Schwab @ 2010-11-10 15:38 ` Stefan Monnier 2010-11-10 17:28 ` Glenn Morris 2 siblings, 1 reply; 35+ messages in thread From: Stefan Monnier @ 2010-11-10 15:38 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > Can you make it just skip merging configure altogether? It "resolves" the conflict automatically by undoing the change. But you could easily add "configure" to the regexp of "commit message words that indicate you might want to skip this commit". It didn't seem worth the trouble since I'd expect "configure" to often be committed together with the corresponding change to configure.in. > It's pointless to merge this generated file between branches, and it > creates merge diffs that are largely noise (eg most recent merge of > emacs23 to trunk). AFAIK the merge I just committed should not have changed ./configure. Stefan ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 15:38 ` Stefan Monnier @ 2010-11-10 17:28 ` Glenn Morris 2010-11-10 20:42 ` Glenn Morris 0 siblings, 1 reply; 35+ messages in thread From: Glenn Morris @ 2010-11-10 17:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier wrote: > AFAIK the merge I just committed should not have changed ./configure. Well, just take a look at the diff: http://lists.gnu.org/archive/html/emacs-diffs/2010-11/msg00141.html By eye, it's about 75% configure. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 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 0 siblings, 2 replies; 35+ messages in thread From: Glenn Morris @ 2010-11-10 20:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel PS I don't recall seeing a compelling reason as to why configure needs to be in the repository at all, so I still suggest just ditching it. (src/config.in is needed by feeble platforms that can't generate it themselves, but AFAIK this does not apply to configure.) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 20:42 ` Glenn Morris @ 2010-11-10 22:30 ` Chad Brown 2010-11-11 4:02 ` Eli Zaretskii 1 sibling, 0 replies; 35+ messages in thread From: Chad Brown @ 2010-11-10 22:30 UTC (permalink / raw) To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel On Nov 10, 2010, at 12:42 PM, Glenn Morris wrote: > PS I don't recall seeing a compelling reason as to why configure needs > to be in the repository at all, so I still suggest just ditching it. In the past, it has been pretty annoying to deal with version skew in autoconf, especially as different gnu packages required different versions (typically a `new/old' split). I've no idea if this is a practical concern today; I do notice that version skew comes up now and then. I hope that helps, *Chad ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 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 1 sibling, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-11 4:02 UTC (permalink / raw) To: Glenn Morris; +Cc: monnier, emacs-devel > From: Glenn Morris <rgm@gnu.org> > Date: Wed, 10 Nov 2010 15:42:46 -0500 > Cc: emacs-devel@gnu.org > > > PS I don't recall seeing a compelling reason as to why configure needs > to be in the repository at all The reason is that if we don't keep it in the repository, everyone should have Autoconf installed. Whether this is "compelling", I don't know. > (src/config.in is needed by feeble platforms that can't generate it > themselves, but AFAIK this does not apply to configure.) True. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 4:02 ` Eli Zaretskii @ 2010-11-11 5:09 ` Kenichi Handa 2010-11-11 19:55 ` Glenn Morris 0 siblings, 1 reply; 35+ messages in thread From: Kenichi Handa @ 2010-11-11 5:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel In article <834obofqyk.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > PS I don't recall seeing a compelling reason as to why configure needs > > to be in the repository at all > The reason is that if we don't keep it in the repository, everyone > should have Autoconf installed. Whether this is "compelling", I don't > know. We can include configure in tarball. For those who get the source from bzr, asking them to install autoconf is, I think, no big deal. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 5:09 ` Kenichi Handa @ 2010-11-11 19:55 ` Glenn Morris 2010-11-11 20:01 ` Lennart Borgman 0 siblings, 1 reply; 35+ messages in thread From: Glenn Morris @ 2010-11-11 19:55 UTC (permalink / raw) To: Kenichi Handa; +Cc: Eli Zaretskii, monnier, emacs-devel Kenichi Handa wrote: > We can include configure in tarball. For those who get the source > from bzr, asking them to install autoconf is, I think, no big deal. Absolutely. I think it is entirely reasonable to say "building Emacs from bzr on a POSIX platform requires autoconf". As a random data point, GNU make apparently did this years ago: http://lists.gnu.org/archive/html/bug-make/2004-02/msg00040.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 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 0 siblings, 2 replies; 35+ messages in thread From: Lennart Borgman @ 2010-11-11 20:01 UTC (permalink / raw) To: Glenn Morris; +Cc: Eli Zaretskii, emacs-devel, monnier, Kenichi Handa On Thu, Nov 11, 2010 at 8:55 PM, Glenn Morris <rgm@gnu.org> wrote: > Kenichi Handa wrote: > >> We can include configure in tarball. For those who get the source >> from bzr, asking them to install autoconf is, I think, no big deal. > > Absolutely. I think it is entirely reasonable to say "building Emacs > from bzr on a POSIX platform requires autoconf". You are not building in the POSIX environment on w32. > As a random data point, GNU make apparently did this years ago: > > http://lists.gnu.org/archive/html/bug-make/2004-02/msg00040.html > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 20:01 ` Lennart Borgman @ 2010-11-11 20:23 ` Óscar Fuentes 2010-11-11 20:49 ` Eli Zaretskii 1 sibling, 0 replies; 35+ messages in thread From: Óscar Fuentes @ 2010-11-11 20:23 UTC (permalink / raw) To: Lennart Borgman; +Cc: Eli Zaretskii, Kenichi Handa, monnier, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: >> Absolutely. I think it is entirely reasonable to say "building Emacs >> from bzr on a POSIX platform requires autoconf". > > You are not building in the POSIX environment on w32. Right. W32 has its own build system that does not rely on autoconf, so W32 is irrelevant on this discussion. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 20:01 ` Lennart Borgman 2010-11-11 20:23 ` Óscar Fuentes @ 2010-11-11 20:49 ` Eli Zaretskii 1 sibling, 0 replies; 35+ messages in thread From: Eli Zaretskii @ 2010-11-11 20:49 UTC (permalink / raw) To: Lennart Borgman; +Cc: monnier, emacs-devel > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Thu, 11 Nov 2010 21:01:15 +0100 > Cc: Kenichi Handa <handa@m17n.org>, Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > > I think it is entirely reasonable to say "building Emacs > > from bzr on a POSIX platform requires autoconf". > > > You are not building in the POSIX environment on w32. A w32 build does not need nor care about the configure script. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-09 21:30 Merging emacs-23 into trunk Stefan Monnier 2010-11-10 4:34 ` Glenn Morris @ 2010-11-10 12:03 ` Eli Zaretskii 2010-11-10 15:46 ` Stefan Monnier 1 sibling, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-10 12:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Date: Tue, 09 Nov 2010 16:30:10 -0500 > > It's [...] scaringly slow (to some extent because of > bzr's braindead lack of support for merging into a tree that's not > clean). I wanted to suggest "merge --force", but I see that you already tried that: > ;; Stupidly, "bzr merge --force -r A..B" dos not maintain the > ;; metadata properly except when the checkout is clean. Do you mean that "bzr merge --force" merges the text, but not the history? If not, what exactly is the problem? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 12:03 ` Eli Zaretskii @ 2010-11-10 15:46 ` Stefan Monnier 2010-11-10 17:21 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Stefan Monnier @ 2010-11-10 15:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> It's [...] scaringly slow (to some extent because of bzr's braindead >> lack of support for merging into a tree that's not clean). > I wanted to suggest "merge --force", but I see that you already tried > that: >> ;; Stupidly, "bzr merge --force -r A..B" dos not maintain the >> ;; metadata properly except when the checkout is clean. > Do you mean that "bzr merge --force" merges the text, but not the > history? Yes: it does merge the history but only in the case where the local tree has no pending merges (in which case bzrmerge can just use "merge -r B") I.e. the result of doing bzr merge -r B is never the same as doing bzr merge -r A bzr merge --force -r A..B While I do expect the two to behave differently w.r.t conflicts (or in the case where A>B, say), I think the fact that the second does not register the revisions from A to B in the "pending merges" data seems like a bug to me. And the fact that bzr merge -r A bzr merge --force -r B applies the A changes twice is another bug. Basically, "bzr merge" completely ignores pending merges. As does "bzr diff" (and probably most/all other commands) BTW. Stefan ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 15:46 ` Stefan Monnier @ 2010-11-10 17:21 ` Eli Zaretskii 2010-11-10 19:03 ` Stefan Monnier 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-10 17:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: emacs-devel@gnu.org > Date: Wed, 10 Nov 2010 10:46:02 -0500 > > bzr merge -r A > bzr merge --force -r A..B > > While I do expect the two to behave differently w.r.t conflicts (or in > the case where A>B, say), I think the fact that the second does not > register the revisions from A to B in the "pending merges" data seems > like a bug to me. You are cherry-picking here; cherry-picking is explicitly not tracked in the history DAG. Why is that a problem, in the context of this discussion (merging from a release branch to the trunk)? > And the fact that > > bzr merge -r A > bzr merge --force -r B > > applies the A changes twice is another bug. I think this is again because cherry-picking is not tracked, so bzr doesn't "know" A is already there. In a nutshell, when you cherry-pick, you need to do your own bookkeeping. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 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:32 ` Óscar Fuentes 0 siblings, 2 replies; 35+ messages in thread From: Stefan Monnier @ 2010-11-10 19:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> bzr merge -r A >> bzr merge --force -r A..B >> >> While I do expect the two to behave differently w.r.t conflicts (or in >> the case where A>B, say), I think the fact that the second does not >> register the revisions from A to B in the "pending merges" data seems >> like a bug to me. > You are cherry-picking here; cherry-picking is explicitly not tracked > in the history DAG. Actually, I'm not cherry-picking: Since all changes until A have been merged, merging A..B will end up with all changes until B: I'm not picking some changes and avoiding others. And indeed bzr merge -r A..B will correctly track the history in the case where A has already been merged and committed. > Why is that a problem, in the context of this discussion (merging from > a release branch to the trunk)? Because, in order to cherry-pick, I merge the various parts of the emacs-23 branch differently, so I need to issue various "bzr merge" commands to merge the branch bit by bit. I could work around this limitation by working on a separate temporary branch (where I can commit after each "bzr merge") and then merge that temporary branch into trunk. >> And the fact that >> bzr merge -r A >> bzr merge --force -r B >> applies the A changes twice is another bug. > I think this is again because cherry-picking is not tracked, so bzr > doesn't "know" A is already there. In a nutshell, when you > cherry-pick, you need to do your own bookkeeping. Where do you see cherry-picking in the above commands: the -r argument always specifies just a revision on the branch, not a "A..B". Stefan ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 19:03 ` Stefan Monnier @ 2010-11-10 19:19 ` Eli Zaretskii 2010-11-10 19:36 ` Óscar Fuentes 2010-11-11 2:52 ` Stephen J. Turnbull 2010-11-10 19:32 ` Óscar Fuentes 1 sibling, 2 replies; 35+ messages in thread From: Eli Zaretskii @ 2010-11-10 19:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: emacs-devel@gnu.org > Date: Wed, 10 Nov 2010 14:03:05 -0500 > > > You are cherry-picking here; cherry-picking is explicitly not tracked > > in the history DAG. > > Actually, I'm not cherry-picking I think you are. From the docs of "bzr merge": When merging a branch, by default the tip will be merged. To pick a different revision, pass --revision. If you specify two values, the first will be used as BASE and the second one as OTHER. Merging individual revisions, or a subset of available revisions, like this is commonly referred to as “cherrypicking”. > Since all changes until A have been merged, merging A..B will end up > with all changes until B: I'm not picking some changes and avoiding > others. And indeed > > bzr merge -r A..B > > will correctly track the history in the case where A has already been > merged and committed. Maybe it's some exception, for when A is the BASE revision; the rule (AFAIU) is what I quote above. When I use "merge -r", I don't expect bzr to track the merge in the branch history. Perhaps you need to ask about this on the Bazaar list. > > Why is that a problem, in the context of this discussion (merging from > > a release branch to the trunk)? > > Because, in order to cherry-pick, I merge the various parts of the > emacs-23 branch differently, so I need to issue various "bzr merge" > commands to merge the branch bit by bit. I still don't understand the problem. Maybe it will become more clear if you could show what you'd like to do, as opposed to what you need to do, due to these limitations. > >> And the fact that > >> bzr merge -r A > >> bzr merge --force -r B > >> applies the A changes twice is another bug. > > > I think this is again because cherry-picking is not tracked, so bzr > > doesn't "know" A is already there. In a nutshell, when you > > cherry-pick, you need to do your own bookkeeping. > > Where do you see cherry-picking in the above commands: the -r argument > always specifies just a revision on the branch, not a "A..B". AFAIU, "-r A" is just a shorthand for "-r A..-1". If A is an arbitrary revision on the branch being merged, you just cherry-pick all the revisions from A to the branch tip. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 19:19 ` Eli Zaretskii @ 2010-11-10 19:36 ` Óscar Fuentes 2010-11-11 6:26 ` Eli Zaretskii 2010-11-11 2:52 ` Stephen J. Turnbull 1 sibling, 1 reply; 35+ messages in thread From: Óscar Fuentes @ 2010-11-10 19:36 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: [snip] > AFAIU, "-r A" is just a shorthand for "-r A..-1". If A is an > arbitrary revision on the branch being merged, you just cherry-pick > all the revisions from A to the branch tip. From "bzr help merge": > To merge changes up to and including revision 82 from bzr.dev: > > bzr merge -r 82 ../bzr.dev So it doesn't mean "from A", but "up to and including A". ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 19:36 ` Óscar Fuentes @ 2010-11-11 6:26 ` Eli Zaretskii 2010-11-11 17:13 ` Óscar Fuentes 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2010-11-11 6:26 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Wed, 10 Nov 2010 20:36:11 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > [snip] > > > AFAIU, "-r A" is just a shorthand for "-r A..-1". If A is an > > arbitrary revision on the branch being merged, you just cherry-pick > > all the revisions from A to the branch tip. > > From "bzr help merge": > > > To merge changes up to and including revision 82 from bzr.dev: > > > > bzr merge -r 82 ../bzr.dev > > So it doesn't mean "from A", but "up to and including A". Okay, but it's still cherry-picking of a certain range of revisions, right? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 6:26 ` Eli Zaretskii @ 2010-11-11 17:13 ` Óscar Fuentes 0 siblings, 0 replies; 35+ messages in thread From: Óscar Fuentes @ 2010-11-11 17:13 UTC (permalink / raw) To: emacs-devel; +Cc: Eli Zaretskii Eli Zaretskii <eliz@gnu.org> writes: >> > AFAIU, "-r A" is just a shorthand for "-r A..-1". If A is an >> > arbitrary revision on the branch being merged, you just cherry-pick >> > all the revisions from A to the branch tip. >> >> From "bzr help merge": >> >> > To merge changes up to and including revision 82 from bzr.dev: >> > >> > bzr merge -r 82 ../bzr.dev >> >> So it doesn't mean "from A", but "up to and including A". > > Okay, but it's still cherry-picking of a certain range of revisions, > right? Nope. It searches the common ancestor and merges from there to A. That's a real VC history merge, i.e. one that preserves commit identity. The last phrase is crucial. If you cherry-picked some commit on that range, bzr does not remember it and it will be merged again, this time preserving its revision id. (I don't know what happens if A was already merged (not cherry-picked)) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 19:19 ` Eli Zaretskii 2010-11-10 19:36 ` Óscar Fuentes @ 2010-11-11 2:52 ` Stephen J. Turnbull 2010-11-11 6:38 ` Eli Zaretskii 1 sibling, 1 reply; 35+ messages in thread From: Stephen J. Turnbull @ 2010-11-11 2:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 2:52 ` Stephen J. Turnbull @ 2010-11-11 6:38 ` Eli Zaretskii 0 siblings, 0 replies; 35+ messages in thread From: Eli Zaretskii @ 2010-11-11 6:38 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: monnier, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, > emacs-devel@gnu.org > Date: Thu, 11 Nov 2010 11:52:38 +0900 > > 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! You of all people should know that in this case Bazaar docs say what the developers meant and faithfully describe what bzr does. (My problem with Bazaar docs is that it doesn't say enough. When it does describe something, the description is usually correct, although it could be misplaced and hard to find.) > There are two different, though closely related, definitions, of > "cherrypicking" in practice. Since this is about Bazaar, I was talking about this meaning, and this meaning alone. > 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. The issue is not whether this bzr behavior is useful. The issue is whether it is by design and documentation. Stefan thinks he was not cherrypicking, so he believes that the parts of the docs I cited are not applicable to what he did. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 19:03 ` Stefan Monnier 2010-11-10 19:19 ` Eli Zaretskii @ 2010-11-10 19:32 ` Óscar Fuentes 2010-11-11 19:57 ` Stefan Monnier 1 sibling, 1 reply; 35+ messages in thread From: Óscar Fuentes @ 2010-11-10 19:32 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> You are cherry-picking here; cherry-picking is explicitly not tracked >> in the history DAG. > > Actually, I'm not cherry-picking: Since all changes until A have been > merged, merging A..B will end up with all changes until B: I'm not > picking some changes and avoiding others. > And indeed > > bzr merge -r A..B > > will correctly track the history in the case where A has already been > merged and committed. No. It will keep the order of the commits, but that's is all it does as far as the VC history is concerned. In general, merge -r A..C is the same as the sequence merge -c A merge -c B merge -c C When you cherry-pick a commit (either individually or as a part of a range) that commit loses its identity and appears as a new one on the target branch. bzr has no way of knowing that a commit you cherry-picked already is on the target branch, and hence it will not complain if you merge it again. `bzr qlog' on trunk just after cherry-picking the changes from emacs-23 will be illustrative. [snip] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-10 19:32 ` Óscar Fuentes @ 2010-11-11 19:57 ` Stefan Monnier 2010-11-11 20:20 ` Óscar Fuentes 0 siblings, 1 reply; 35+ messages in thread From: Stefan Monnier @ 2010-11-11 19:57 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel >>> You are cherry-picking here; cherry-picking is explicitly not tracked >>> in the history DAG. >> Actually, I'm not cherry-picking: Since all changes until A have been >> merged, merging A..B will end up with all changes until B: I'm not >> picking some changes and avoiding others. >> And indeed >> bzr merge -r A..B >> will correctly track the history in the case where A has already been >> merged and committed. > No. It will keep the order of the commits, but that's is all it does as > far as the VC history is concerned. I have no idea what you mean by the above, but I have tried and tested bzr merge -r A..B and in all my tests, in the case where A has already been merged into the current tree, it behaves exactly like bzr merge -r B with respect to history-tracking. Stefan ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-11 19:57 ` Stefan Monnier @ 2010-11-11 20:20 ` Óscar Fuentes [not found] ` <jwvd3qbo3z1.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 35+ messages in thread From: Óscar Fuentes @ 2010-11-11 20:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>> You are cherry-picking here; cherry-picking is explicitly not tracked >>>> in the history DAG. >>> Actually, I'm not cherry-picking: Since all changes until A have been >>> merged, merging A..B will end up with all changes until B: I'm not >>> picking some changes and avoiding others. >>> And indeed >>> bzr merge -r A..B >>> will correctly track the history in the case where A has already been >>> merged and committed. > >> No. It will keep the order of the commits, but that's is all it does as >> far as the VC history is concerned. > > I have no idea what you mean by the above, but I have tried and tested > > bzr merge -r A..B > > and in all my tests, in the case where A has already been merged into > the current tree, it behaves exactly like > > bzr merge -r B > > with respect to history-tracking. Yes, when A (or its parent) already is on the target branch with the same revision-id as it has on the source branch. But if you cherry-picked A (instead of merging it) you will end with two instances of the commit that corresponds to A in the VC history: one corresponds to the cherry-pick and another to the merge. (It is unfortunate that `bzr merge' is used for merging history and for cherry-picking). Another case is when the parent of A is not on the target branch (with the same revision-id it has on the source branch.) Then you are cherry-picking a series of commits. ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <jwvd3qbo3z1.fsf-monnier+emacs@gnu.org>]
* Re: Merging emacs-23 into trunk [not found] ` <jwvd3qbo3z1.fsf-monnier+emacs@gnu.org> @ 2010-11-12 16:51 ` Óscar Fuentes 2010-11-12 20:41 ` Stefan Monnier 0 siblings, 1 reply; 35+ messages in thread From: Óscar Fuentes @ 2010-11-12 16:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> Yes, when A (or its parent) already is on the target branch with the >> same revision-id as it has on the source branch. > > Which is exactly the situation I was talking about: > > And indeed > bzr merge -r A..B > will correctly track the history in the case where A has already been > merged and committed. "merge -r A..B" usually means a cherry-pick, because for the case when it is a merge there is no reason to specify A (the tool figures it out automatically) but it seems that you missed the syntax "merge -r B" ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Merging emacs-23 into trunk 2010-11-12 16:51 ` Óscar Fuentes @ 2010-11-12 20:41 ` Stefan Monnier 0 siblings, 0 replies; 35+ messages in thread From: Stefan Monnier @ 2010-11-12 20:41 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel >>> Yes, when A (or its parent) already is on the target branch with the >>> same revision-id as it has on the source branch. >> >> Which is exactly the situation I was talking about: >> >> And indeed >> bzr merge -r A..B >> will correctly track the history in the case where A has already been >> merged and committed. > "merge -r A..B" usually means a cherry-pick, In the context of "where A has already been merged and committed", it's not "usually" a cherry-pick: it's never a cherry-pick. > because for the case when > it is a merge there is no reason to specify A (the tool figures it out > automatically) but it seems that you missed the syntax "merge -r B" No, I didn't miss this syntax (as you can tell by looking at the code I sent ;-). Stefan ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2010-11-12 20:41 UTC | newest] Thread overview: 35+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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.