-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git submodule support #46
Conversation
That's what the pkgmeta is for. submodules are fine if you want to use them for development, it was a design choice to not implement git submodules, svn externals, and mercurial subrepos |
If your main goal is to pin a certain commit to be used, a proper method would be to add support for that through pkgmeta (ie. by specifying the hash/commit to be used similar to how you would a tag), that way you can also use libraries in other repository types, eg. a SVN library in your Git project, and still pin a specific version. |
Yes nev that was my goal was to point it at a specific commit. I ran into a case where a lib did not have a tag so I either had to fork the lib so I could add a tag of where I wanted my code to run off of or use a submodule. Submodule seemed easier. |
Easier perhaps, but only as long as everything is Git. Back in the old days we all used SVN and managed libraries using svn:external, but then people started using Git and Hg, and we had problems - hence pkgmeta was born to offer a more portable solution independent of VCS-specific features. Hence the resistance to go back to those VCS-specific solutions now, and rather push for a solution that fits the entire spirit behind the design here. Something like this could solve the same problem, afterall, but also work in more cases:
|
Actually, I will add this, it makes it consistent with the other types for externals at least. The way svn:externals is handled for ignores was what I was thinking about, but that was more a convenience thing for how old projects worked, so it doesn't make much sense to arbitrarily restrict how people are using their repo. I do think handling things with pkgmeta is better to keep things consistent overall, though, especially if the library is on cf. |
Also, you can put any committish in the tag line and it will check that out Edit: Well that's not true, but I'll fix that |
Example of submodules in use: MaxDPS has StdUi as a submodule or SpartanUI has SUF and StdUi as submodules with this PR no reference is needed in the pkgmeta git handles getting all the files and most importantly ensures the proper commit is used.
There is no harm in using recursive when no submodules are present git just ignores it.