From 063c9f1f10e88a6eaeeb6781a12aa208038e3852 Mon Sep 17 00:00:00 2001 From: aryan Date: Mon, 20 Jun 2022 05:23:59 -0700 Subject: [PATCH 1/2] should work on your computer now --- winConfig.bat | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/winConfig.bat b/winConfig.bat index 85f4b61..2c905e2 100644 --- a/winConfig.bat +++ b/winConfig.bat @@ -1,5 +1,7 @@ -echo on +echo off call C:\"Program Files (x86)"\"Microsoft Visual Studio"\2022\BuildTools\VC\Auxiliary\Build\vcvarsamd64_x86.bat +call C:\"Program Files"\"Microsoft Visual Studio"\2022\Community\VC\Auxiliary\Build\vcvars64.bat" +echo on cd libsodium msbuild libsodium.vcxproj -p:Configuration=Release;Platform=x64;PlatformToolset=v143;WindowsTargetPlatformVersion=10.0 -m echo off From 3f38b6192b857f8cad28a720a314de65635487df Mon Sep 17 00:00:00 2001 From: aryan Date: Tue, 28 Jun 2022 16:09:48 -0700 Subject: [PATCH 2/2] documenting setup from clone --- docs/libraries.md | 59 ++++++++++++++++++++++++++--------------- docs/rootDocs/README.md | 7 +++++ 2 files changed, 44 insertions(+), 22 deletions(-) diff --git a/docs/libraries.md b/docs/libraries.md index b0f0981..ab14d36 100644 --- a/docs/libraries.md +++ b/docs/libraries.md @@ -95,7 +95,7 @@ Libraries are best dealt with as [Git submodules]. [build libraries]:https://git-scm.com/book/en/v2/Git-Tools-Submodules -Git submodules leak complexity and surprising and inconvenient behavior +Git submodules leak complexity and surprising and inconvenient behaviour all over the place if one is trying to make a change that affects multiple modules simultaneously. But having your libraries separate from your git repository results in non portable surprises and complexity. Makes it hard @@ -134,19 +134,29 @@ tag, not by branch, and the names of branches are only used to communicate a particular project on the submodule to other people working on that project as their master project. -Branch names are not useful within a submodule, though -submodule may well be, from the point of view of the primary -developers, not a submodule but a module in its own right, used as -a submodule in many different modules, so for them, branch names -will be useful. But when you are modifying the submodules in a -project as a single project, making related changes in the module -and submodule, the names belong in the primary project module, -Within the submodule, commits are nameless with detached head, -the name in primary module naming a group of related commits in -several submodules, which commits do not usually receive -independent names of their own, even though the commits have to -be made within the submodule, not in the containing module which -names the complete set of interrelated commits. +Branch names within a submodule, though very useful when you working +on a submodule, are not useful to the project as a whole, and except for the +primary fork name, should be temporary and local., not pushed to the +project repository, But when you are modifying the submodules in a +project as a single project, making related changes in the module and +submodule, the shared names that are common to all developers belong in +the primary project module,and when you have done with a submodule, + +```bash +git switch --detach +``` + +Within the submodule, commits are nameless with detached head, except +when you are working on them, the name in primary module naming a +group of related commits in several submodules, which commits do not +usually receive independent names of their own, even though the commits +have to be made within the submodule, not in the containing module +which names the complete set of interrelated commits. + +The submodule commits may well belong to different branches and tags in +the superproject, but in the submodules, they are nameless in that all the +submodule commits wind up attached to the same branch, your submodule tracking +branch. In this case, working on submodules as part of a single larger project, you should set @@ -182,19 +192,24 @@ Make sure things still work. Get everything working. (You do have unit test, r then: ```bash -git submodule foreach --recursive 'git push origin HEAD:«your-tracking-branch»' git submodule foreach --recursive 'git switch --detach' +git submodule foreach --recursive 'git push origin HEAD:«your-tracking-branch»' ``` +You pull a named release of the project that is a submodule of your project +from `upstream`, diddling with it to make it work with your project, then +you push it to `origin` as a nameless commit, though you probably gave the +various commits you made while working on it temporary and local names +with `switch -c yet-another-idea` All of which, of course, presupposes you have already set unit tests, upstream, origin, and your tracking branch appropriately. -Even if your local modifications are nameless in your local -submodule repository, on your remote submodule repository they -need to have a name to be pushed to, hence you need to have a -tracking branch in each of your remote images of each of your -submodules, and that tracking branch will need to point to the root -of a tree of all the nameless commits that the names and commits +Even if your local modifications are nameless in your local submodule +repository, on your remote submodule repository they need to have a name +to be pushed to, hence you need to have a tracking branch in each of your +remote images of each of your submodules, and that tracking branch will +need to point to the root of a tree of all the nameless commits that the +names and commits in your superproject that contains this submodules point to. You want `.gitmodules` in your local image of the repository to @@ -241,7 +256,7 @@ means you can incorporate unlimited amounts of stuff, and Git only has to check the particular module that you are actually working on. Maybe subtrees would work better if one was working on a project where -several parts were being developed at once, thus a project small enough +several parts wer e being developed at once, thus a project small enough that scaling is not an issue. But such projects, if successful, grow into projects where scaling is an issue. And if you are a pure consumer of a library, you don't care that you are breaking the git model, because you are diff --git a/docs/rootDocs/README.md b/docs/rootDocs/README.md index 7baac33..6500ad8 100644 --- a/docs/rootDocs/README.md +++ b/docs/rootDocs/README.md @@ -120,6 +120,13 @@ unless you tell `gpg` to trust the key that is in the root directory as Never check any Gpg key related to this project against a public gpg key repository. It should not be there. +`gitconfig` disallows merges unless you have told `gpg` to trust the public +key corresponding to the private key that signed the tip of the root. So part +of the pull request process is getting the puller to trust your public key, and +you will not be able to pull updates unless you tell `gpg` to trust the key that +is in the root directory as `public_key.gpg`. + + Never use any email address on a gpg key related to this project unless it is only used for project purposes, or a fake email, or the email of an enemy. We don't want Gpg used to link different email