72191Re: Vim development process is utterly broken (Was: Re: [patch] test98 stops when using gvim)
- Jul 15, 2013
> Since we're using Mercurial, and Bram wants to allow email submissions, a developer can email a "bundle" if he/she doesn't have/want access to a public repository. Then just the commits required for the fix (with some commit also in Bram's repository as a parent) need to be emailed, and he can import or pull from the bundle.Bundles solve exactly one problem: they avoid problems with applying patches. They do introduce another problem: now it is tricky to see the diff (any discussion around PR’s assumes having web interface for them). With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
> I'm not altogether opposed to using patches for an initial solution, but at some point the patch needs to go into a real commit so people can review it BEFORE it gets released officially.It is part of what (a successful) git-flow model suggests. As far as I see git-flow suits perfectly for mercurial as well.
> I think using rebase risks some of the same problems that patches have, so a completely linear history may be harder to keep. But, Bram can at least keep using a linear set of tagged revisions with nothing in between, by updating the version.c version number and applying a tag after every merge he intends to publish.
Note that rebasing of a commit from third-party source is tricky because mercurial uses phases for preventing you from doing such mistake.
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+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.
- << Previous post in topic Next post in topic >>