2015-03-29 15:55 GMT+03:00 Fredrik Gustafsson <[email protected]>: > 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?"
I am speaking exactly about doing the development which will result in /runtime/ changes. Note: if that was mercurial you can simply create a new branch head; it is supposed to be merged at the time main repository is merged. Git does not have mercurial branches so this is not an option. > > 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 means losing one of the main points (/runtime/ is considered to be updated more often then /, so some people do not want to wait until Bram merges it in /). > > This a really good design if you need to work with a submodule with a > different release cycle, for example a third party library. Which is the job for the package manager and not submodules. Submodules are for the case when you do development in all projects, and such projects are both not too closely tied to keep in one repository and not too loosely tied to make them completely separate projects. > >> 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)). Blindly removing directory will result in possibility of losing changes. Regular check out will fail if git is not able to merge uncommitted changes into new revision, but this is not the case if you remove changes yourself. Also main point is that it would be impossible to do *with `git checkout`* not *at all*. I have not stressed this, but this point is actually about “using old commits will become rather inconvenient”. > >> 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. Which is what I mean about being careful. You need to merge it in the other location *and then make sure that you pointed out the /runtime/ merge commit when merging /*. Also I smell merge conflicts out of nothing. > > > 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. Note that most of the issues I am pointing out are issues because we are discussing splitting documentation from source code. It would make sense to move xxd to a submodule because changes to xxd which result in changes to Vim (not to mention the opposite) are very rare and xxd is not used without Vim (if you absolutely need exactly xxd output it is completely possible to configure hexdump to make it; writing script which dumps binary file out of the output is trivial). > > > -- > 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.
