> 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. > > 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. It is part of what (a successful) git-flow model suggests. As far as I see git-flow suits perfectly for mercurial as well. 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
