I have a submodule which I would like to be used in two modules. Is it possible to use the one submodule in multiple modules and how to do that?
No. A submodule may only belong to one module and may be included only by its main module or a submodule that belongs to the same main module.
Submodules are partial modules that contribute definitions to a
module. A module may include any number of submodules, but each
submodule may belong to only one module.
RFC7950, Section 5.1, Modules and submodules
A submodule MUST only be included by either the module to which it
belongs or another submodule that belongs to that module.
RFC7950, Section 7.2.2, The "belongs-to" statement
Related
I have a multi module GitHub project which I would like to build using GitHub actions. The action script that I have written is a publish script that triggers when a tag is pushed. I need two things here that should work out, but before here is my project structure:
main-project:
build.sbt
module1:
build.sbt
src/main/scala/....
module2:
build.sbt
src/main/scala/....
I need to have a mechanism check that does the following:
When I push a tag, I will trigger my workflow and I would like that my workflow is only publishing module 1 changes
Is there a way to git tag only module 1?
If you only ever want to publish module1, you can set publish / skip := true in the project settings in build.sbt for other modules and the root project.
If your modules are on different paths within the same Git repository, you could use a path-filter action, as illustrated here.
Note that you cannot tag just a part of a repository, but, if your changes involves only that one module, you can then decide apply a (global) tag with a naming convention reflecting the nature of the change (IE only module1 or only module2).
I've two Swift PM projects, both use some common code which I would like to store perhaps in a separate project, say a library, which then these two would be able to import.
I've used swift init --type library and so on to build a library but is there any other documented way of including it in the other projects without having to submit it to github and providing the link to the repo to the swift package manager?
I'm thinking something around the lines of building the library project and having a script which copy pastes it wherever it needs to be to be accessible to the other projects (in their own directories if need be)
According to the Swift Package Manager Usage documentation a swift package is designed to be used as a git repository.
Simply put: a [Swift] package is a git repository with semantically versioned tags, that contains Swift sources and a Package.swift manifest file at its root.
That said, the dependencies documentation section states that the depedency path can be a local path.
[Dependencies] is the list of packages that the package depends on. You can specify a URL (or local path) to any valid Swift package.
Note that the git tags are useful (needed) to manage which version of a dependent package is included.
// 1.5.8 ..< 2.0.0
.package(url: "path/SharedPackage", .upToNextMajor(from: "1.5.8")),
// Constraint to an arbitrary closed range.
.package(url: "path/SharedPackage", "1.2.3"..."1.2.8"),
// Branch and revision.
.package(url: "path/SharedPackage", .branch("develop")),
Key Points:
Treating the local package as the same local git repository could still align one's workflow with the Swift Package Manager design.
Some remote or additional git repository is not required because local dependency paths of the Swift package(s) can be used.
Basically, using git in a more simplified and streamlined way may be worth considering for the local-only, some-shared-code use case.
To prevent copy/pasting foreign code to my github repository I would like to refer from my project (in specific dir) another project files (of the specific revision)
To make things clear I'd like to achieve situation like in this repo: https://github.com/husio/vim-configuration/tree/master/bundle
How can I do so?
Not sure if it's a github only feature, or somehow git itself supports it.
You are looking for git submodules. It is a feature of git, but GitHub's file browser will resolve submodules when you view them on the site (which is what you can see in the repository you linked to).
Note that while submodules let you choose their location (within your repository), name, and commit (from the submodule's repository), they will include the entire trees of the original repositories. If you only want specific files or directories, check out subtree merge instead.
I am having trouble setting up a project in Mercurial with subrepos.
Goal:
I want to set up the structure like so:
-- Build_Repo (this repo will be used to track dependencies)
-- Subrepo_A (this is the main source)
-- Modules (Part of Subrepo_A)
-- Subrepo_B
So there are three repos: Build, A, and B. B is nested inside A, A is nested inside the root build repository. The build repo will be used to track dependencies, subrepo A will be used to track the main source files, and subrepo B (and others) will be used to track module/plugin development.
Problem/Question
I have no problem setting up the initial build repo and the nested Subrepo_A by simply adding the Subrepo_A path and source to the .hgsub file and committing it to the build repo. However, when after I add the subrepo_B path/source to the build repo's .hgsub, and then try to commit I get the error message:
abort: path 'Subrepo_A/Modules/Sebrepo_B' is inside nested repo 'Subrepo_A'
Mercurial doesn't appear to like a nested repo inside an already nested repo. Is this true, or am I missing something? Any better ideas on how to manage builds/dependencies?
The problem here is one of Mercurial's inescapable constraints: a repository corresponds to a folder tree on your computer. The repository is responsible for everything under that folder tree.
When your top-level repository includes a sub-repository, it hands over to the sub-repo complete control of that part of its folder structure. So the top level can't specify another sub-repository somewhere in the first sub-repos folders.
Solution 1
Subrepo_B is actually a dependency of Subrepo_A. In that case, make your repositories reflect the true dependency by editing Subrepo_A's .hgsub file to add Subrepo_B under Modules/Sebrepo_B. This works because Subrepo_A retains control over its folders.
Solution 2
Subrepo_A doesn't depend on Subrepo_B, you were putting it there for convenience. In this case, you should make both Subrepo_A and Subrepo_B be subrepos (in different locations) of the Build_Repo.
In your situation, you'll have to add subrepoB to subrepoA.
I would suggest trying to move dependencies so that your tree only has 2 levels, but that may not be possible. It's always not a very smooth experience otherwise.
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo]
- ...with some extra files from me
- externalLibraryB [comes from a SVN repo]
- ...with some extra files from me
- externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771