On Apr 2, 2014 1:54 AM, "Ben Fritz" <fritzophre...@gmail.com> wrote: > > On Tuesday, April 1, 2014 10:53:38 AM UTC-5, ZyX wrote: > > > > 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. > > > > > > I agree with all this. But Bram refuses to pull directly from other repositories and then merge. So if I use normal Hg changesets with merging, I will always have my own personal branches hanging around. Even if I merge and close the branch with a commit, that merge commit will never be an ancestor of the commits I pull from Bram. So I will eventually just need to delete my changesets to remove the dead branch. Additionally, since Bram won't pull and merge, I need to send changes based off the latest changes HE has made to make him more likely to accept them.
After you did a merge sending update is trivial (except for a sequence of patches I mentioned: in this case you either need to actually rebase or have a sequence of merge commits). Mercurial is also fine with dead branches hanging around and you can always view only ancestors of a certain changeset. Absence of upstream merges is not fine, but all attempts to convince Bram failed so far. > > Either rebasing changesets, or doing a qpop+update+qpush, are easy ways to do this. > > > 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. > > > > This is true. I learned MQ before phases were introduced and in general am not very comfortable in editing history even in secret. > > I view MQ changesets not so much as normal changesets in Hg, but rather a group of in-progress patches applied on top of an actual repository. In Vim's case, that repository is for my purposes pretty much read-only. I don't commit any Vim code changes (on the rare occasions I make them). Rather I qpush them. When the change appears in the upstream repository as an official patch, I qpop and forget about my changeset. I know under the hood this is acutally editing history...but it doesn't FEEL like that's what I'm doing. > > I understand changeset obsolescence and history editing are intended to replace MQ to accomplish the same things, however. If you keep old history you can review what *Bram* has changed in your patch. You will need to rebase to/merge the changeset just before upstream inclusion though. > > -- > -- > 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. -- -- 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.
