Christian Brabandt wrote: > On So, 30 Mär 2014, Ben Fritz wrote: > > On Saturday, March 29, 2014 10:10:03 AM UTC-5, Bram Moolenaar wrote: > > > I have asked Christian Brabandt to write down how he creates and > > > maintains patches for Vim. You can read it here: > > > > > > http://www.vim.org/develop.php > > > > > > I hope this is useful. If you have suggestions to improve this page, > > > please discuss here. > > > > > > > Nice! I have a couple suggestions: > > > > First, this part I think has a typo: > > > > > So you save your work, refresh the current patch and fix that small bug > > > with a new patch: > > > > > > ~/code/vim $ hg qrefresh > > > popping my_fancy_feature > > > patch queue now empty > > > > Shouldn't that be qpop instead of (or in addition to) qrefresh? > > Yes the qpop is missing. It should be: > ~/code/vim $ hg qrefresh > ~/code/vim $ hg qpop > popping my_fancy_feature > patch queue now empty > > > > 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: > > > I think "hg pull" without the "-u" flag, so that you can at least preview > > the incoming changes, would actually be a good thing. Just make sure to > > "hg qpop -a" before doing an "hg update". > > > > Finally, it is OK to use mq in a repository others can pull from, if you use > > the relatively new "phases" feature to hide your mq changesets from anybody > > doing a "pull". You do this by enabling the "secret" option in mq, to make > > any changesets created by the extension hidden from others on pull or push: > > > > http://mercurial.selenic.com/wiki/MqExtension#Ensure_patch_queue_changesets_use_secret_Phase > > I saw this on that webpage. But I didn't want to confuse by introducing > yet another option of which I don't if it is available at all clients. > So how about this: > > Don't use MQ in a repository anyone might pull from (unless you hide > your mq changesets away using the <a > href='http://mercurial.selenic.com/wiki/MqExtension#Ensure_patch_queue_changesets_use_secret_Phase'>secret > > phase</a>)
Thanks for the changes, I'll update the page. -- hundred-and-one symptoms of being an internet addict: 10. And even your night dreams are in HTML. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
