Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

Wutname1
Copy link

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.

@nebularg
Copy link
Member

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

@nebularg nebularg closed this Oct 25, 2019
@Wutname1 Wutname1 deleted the SubmoduleSupport branch October 25, 2019 04:05
@BigWigsMods BigWigsMods deleted a comment from mooreatv Oct 25, 2019
@Nevcairiel
Copy link
Member

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.

@Wutname1
Copy link
Author

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.

@Nevcairiel
Copy link
Member

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:

externals:
  Libs/LibBanana-1.0:
    url: https://github.com/monkehdude/LibBanana-1.0.git
    commit: ca82a6dff817ec66f44342007202690a93763949

@nebularg
Copy link
Member

nebularg commented Oct 25, 2019

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.

@BigWigsMods BigWigsMods deleted a comment from mooreatv Oct 25, 2019
@nebularg
Copy link
Member

nebularg commented Oct 25, 2019

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

nebularg added a commit that referenced this pull request Oct 25, 2019
@Wutname1
Copy link
Author

352df5b looks good, thanks @nebularg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants