vovaho.blogg.se - Git submodule point to branch

Git submodule point to branch how to#
Git submodule point to branch update#
Git submodule point to branch full#
Git submodule point to branch code#

It seems to me that the development process will have to change considerably in any case. it is the only solution that does not involve any complication over the status quo. Furthermore, if the change is not a bug fix then one has to wait on average three months between the two PRs for the next release of DBCSR. And the second PR will point CP2K's submodule to the new version of DBCSR. The first PR will get the change into DBCSR. Of course pointing it at a sha means that it will always take two PRs to a make a combined cp2k/dbcsr change. Otherwise we'd lose track over which combinations work. Wait, are you planing to point the submodule at the branch head, like #86 currently does? I always assumed that we would point the submodule at a fixed sha or at least a tag. I think we are not ready yet to make DBCSR fully external to CP2K, especially now that we are about to change dbcsr_api module ( cp2k/dbcsr#109).

Git submodule point to branch how to#

This is how I imagine CP2K/DBCSR development in the future, and it is the only solution that does not involve any complication over the status quo (except of some knowledge required how to deal with git submodules). Why should we discourage such a case? I thought the whole point of using git submodule is to allow tightly coupled development on CP2K and DBCSR in the future even though DBCSR is a standalone repositoryĮxts/dbcsr is not supposed to be used by developers, changes only every ~6 months, and will most likely disappear in a year or so.Įxts/dbcsr may rarely change on CP2K master branch, however CP2K/DBCSR developers will point the dbcsr submodule to their own DBCSR fork. Actually, we have to discourage such a case, otherwise the DBCSR standalone would be pointless. This is true, however it is not suggested to develop DBCSR within CP2K. The entire discussion is useless if we don't start. I don't see any deadline (did I say 1 year?).

For bug fixing, CP2K can use a different branch.

So, I add another bullet for the requirements: It turns out that the best match for solving this case is to use the submodules:Ī) Easy DBCSR testing: we can have a regtest for CP2K will uses DBCSR develop branchī) Easy DBCSR fixing within CP2K: suggested to have a "cp2k" branch in DBCSR to cover those cases (bug fixing) so that CP2K can evolve before making an official DBCSR release (and sync once is done) The two packages are tightly coupled (DBCSR needs CP2K for testing and CP2K needs DBCSR for working). Now, what if there is a bug in DBCSR, which is CP2K specific? This is not rare since CP2K is heavily using DBCSR and DBCSR unittests are not covering all possibilities. For instance, they cannot add a new functionality and report: "it is tested by CP2K, so I don't need to test within DBCSR".

People have to work on the DBCSR repository for any major development.

master gets only official release, ~6 months cycle (git workflow).

exts/dbcsr links to master, so it cannot be used by developers (unless they change branch for their internal work, but then I assume they know what they are doing).

The summary is almost correct, we are on the same line for the main points.

Git submodule point to branch full#

and based on feedback from discussions with a guest in our group I'm preparing a full developer's guide.

Git submodule point to branch update#

# you have to update the submodules separately by running:

# or if you have updated an existing clone from before for the first time, # If your Git version is older than 2.14, Your clone of the Git repository (any branch) can be updated using the following commands: Git config -global submodule.recurse true Since CP2K uses Git Submodules, make sure to configure your Git installation to automatically update any submodules (run this command only once on a machine): Git clone -recursive -b support/v6.1 cp2k Or to directly checkout a branch (check the ] for available branches): The latest and all prior versions are available from the ].

The ] (''git'') program must be installed on your machine for this to work.

Git submodule point to branch code#

The code in Git is under constant development.