On Sunday, March 29, 2015 at 2:10:09 PM UTC+3, Fredrik Gustafsson wrote: > On Sun, Mar 29, 2015 at 04:04:23AM -0700, ZyX wrote: > > On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote: > > > On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote: > > > > NeoVim project tried to do this and found it non-comfortable to keep > > > > them in > > > > sync (I mean, any contributor which needs to change both code and > > > > documentation needs to create two separate pull requests). > > > > > > > > Thus if runtime will be separated at least runtime/doc should be kept > > > > in main > > > > repository. Submodules suggested later cannot solve this issue at all. > > > > > > I fail to understand why submodules cannot solve this problem. Would you > > > care to elaborate? > > > > Please show me an example of the PR which will update *both* the main > > repository and the submodule. If this is possible then submodules can solve > > this problem, but I have never seen this functionality. > > Thanks I see your point. You first have to make a pull request to the > submodule and then a new pull request telling the parent repo to use > that new submodule commit. This can of course lead to a state where we > have dead code in the submodule. That is, code not used in the parent > repo yet because it haven't been merged but the code in the submodule > has. > > That is if we don't apply commits in the same order for the submodule > and the parent. > > So I see a problem in needing to do a two step pull request cycle, and a > possibility for dead code inte the submodule.
This is not dead code, this is primary out-of-sync documentation (since unlike NeoVim Vim does not have that much supporting code in runtime: NeoVim has various providers there, Vim only things like runtime/syntax.vim). > > This is bad, maybe bad enough, technically it would work though. Or am I > missing some additionally pitfall? Double and linked PRs are the primary problem. Also note that mercurial developers consider this a “feature of last resort”. Don’t know why exactly, but I believe they know what they are doing. There are another problems with submodules: 1. They are checked out in “detached HEAD” state. This means that you need to do development in another clone or constantly do `git checkout` in submodules (once per each `git submodule update` call). 2. Every time submodule is updated upstream must be updated as well. This means additional work for maintainers (can be redirected to a script though). 3. If Vim will start using submodules from some commit *and* will still have in-repository `runtime` directory in preceding commit it would be impossible to use `git checkout` to switch to older commit. 4. Switching to some commit will now always be `git checkout` followed by `git submodule update`. 5. You can’t merge submodule changes. For top-level repository submodule is effectively just a binary file with SHA and if you do merging you need to be careful regarding what the result of the merge will be and what it should be. > > -- > Fredrik Gustafsson > > phone: +46 733-608274 > e-mail: [email protected] > website: http://www.iveqy.com -- -- 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.
