On Apr 1, 2014 7:42 PM, "Ben Fritz" <[email protected]> wrote: > > On Monday, March 31, 2014 9:04:50 PM UTC-5, Danek Duvall wrote: > > Christian Brabandt wrote: > > > > > > Secondly, I disagree that "It is dangerous to pull changes from the central > > > > vim repository, while there are still patches applied." Pulling with patches > > > > applied always works just fine, the mq patches act just like real Mecurial > > > > changesets. What you don't want to do, is update after a pull with the > > > > patches still applied, because then you need to back up to a different > > > > changeset to unapply the patches. But even update isn't "dangerous". What > > > > would be bad is trying to merge the upstream changes into your mq patches > > > > using Mercurial merge commands. > > > > > > Yes, that's what I meant. So, to how about this: > > > > > > It is dangerous to pull changes from the central vim repository and > > > update your working copy at the same time (-u flag), while there are > > > still patches applied. Instead, make sure to pop all patches, update the > > > repository and push your patches again: > > > > You may be better off enabling the rebase extension and running > > "hg pull --rebase", since that will enable mercurial's merging > > mechanics, rather than the qpop/qpush pair, which will (if there are > > conflicts) leave patch reject files lying around, which you then need > > to merge manually. > > > > Does "rebase" integrate with MQ to set up the queue base changeset and > such properly? I really, really don't like the idea of messing around > with MQ changesets in this way, unless I know it works. > > I saw recently on the Mercurial mailing list that MQ is planned for > deprecation (still supported, but not recommended for new users). One of > the suggested replacements was "changeset evolution" combined with > rebase, histedit, and strip if needed. The idea was to use normal > changesets with the "secret" phase on so you could use all the internal > Mercurial machinery better. But I don't know how mature this approach > is, and I'm having a little trouble wrapping my mind around it without > trying it out first. I already know how to work with MQ, on the other > hand.
I am wondering why you need any rebasing in the first place? I use regular mercurial branches or bookmarks and regular "hg merge". If you are not going to release a series of related patches (which depend on each other) this approach is far better: 1. You are not losing context in which changes were made. 2. If you do a mistake while dealing with conflict this mistake will be attached to merge changeset, not to the original change. 3. It is easy to distribute changes. No secrecy, just push to your public repo. Bitbucked supports or used to support MQ, but I failed to setup it. Though I did not try hard, just was investigating whether dealing MQ is worth learning. 4. You do not need to learn MQ in addition to learning mercurial. Additionally if the phase of changesets is secret you can as well rebase regular mercurial changesets. > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
