On Sun, Mar 29, 2015 at 05:15:08AM -0700, ZyX wrote: > 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).
That would then require that not to add a submodule to the parent which contain changes that not have their corresponding part merged into the parent yet. Not impossible but not very practical. I believe this is the real dealbreaker. It all depends on how tightly coupled the runtime is with the parent repo. Thanks for clarifying this. Let me comment purely technical: > > 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). You don't have to do a checkout to a branch unless you need to work on that submodule. And I can't really see how this could be done in any other way. Do you have a better solution than the "checkout to detached state?" With git there's possibilities to automatically point a submodule to a branch today, but that's stupid because things will break. > 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). No. You don't need to update the parent just because the submodule is updated. However if you want the parent to use the new version of the submodule then you've to update the parent. This a really good design if you need to work with a submodule with a different release cycle, for example a third party library. > 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. Yes, this is sad. Work is beeing done to remove this obstacle (and you can checkout an older commit, but you first have to remove the directory containing the submodule (don't worry, it will be restored when you checkout a commit using that submodule again)). > 4. Switching to some commit will now always be `git checkout` followed by > `git submodule update`. yes > 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. You can merge submodules, but not from the point of the parent repo which will see the submodule as a binary file. Let me add that I've no reason for promote vim using submodules, but I want the discussions to be hold with the correct technical background. -- 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.
