cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

recovered some lost documentation

Browse Source
This commit is contained in:
Cheng 2022-06-19 21:04:27 +10:00
parent 5364b3f770
commit 762cfa6f53
No known key found for this signature in database
GPG Key ID: D51301E176B31828
5 changed files with 143 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
docs/libraries.md
View File

@ -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

6
docs/pandoc_templates/style.css
View File

@ -1,6 +1,12 @@
body {
max-width: 30em;
margin-left: 1em;
font-family: "Georgia, Times New Roman", Times, serif;
font-style: normal;
font-variant: normal;
font-weight: normal;
font-stretch: normal;
font-size: 16px;
}
table {
border-collapse: collapse;

7
docs/rootDocs/README.md
View File

@ -84,6 +84,13 @@ Never --sign any Gpg key related to this project. --lsign it.
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

52
docs/set_upstream.sh Normal file
View File

@ -0,0 +1,52 @@
#!/bin/bash
set -e
set -x
echo intended to be run in the event of moving repositories
git remote -v
git remote set-url origin git@cpal.pw:~/wallet.git
git submodule foreach --recursive 'git remote -v'
cd libsodium
git remote set-url origin git@cpal.pw:~/libsodium.git
git remote set-url upstream https://github.com/jedisct1/libsodium.git
cd ..
cd mpir
git remote set-url origin git@cpal.pw:~/mpir.git
git remote set-url upstream https://github.com/BrianGladman/mpir.git
cd ..
cd wxWidgets
git remote set-url origin git@cpal.pw:~/wxWidgets.git
git remote set-url upstream https://github.com/wxWidgets/wxWidgets.git
cd ..
cd wxWidgets/3rdparty/catch
git remote set-url origin git@cpal.pw:~/Catch.git
git remote set-url upstream https://github.com/wxWidgets/Catch.git
cd ../../..
cd wxWidgets/3rdparty/nanosvg
git remote set-url origin git@cpal.pw:~/nanosvg
git remote set-url upstream https://github.com/wxWidgets/nanosvg
cd ../../..
cd wxWidgets/3rdparty/pcre
git remote set-url origin git@cpal.pw:~/pcre
git remote set-url upstream https://github.com/wxWidgets/pcre
cd ../../..
cd wxWidgets/src/expat
git remote set-url origin git@cpal.pw:~/libexpat.git
git remote set-url upstream https://github.com/wxWidgets/libexpat.git
cd ../../..
cd wxWidgets/src/jpeg
git remote set-url origin git@cpal.pw:~/libjpeg-turbo.git
git remote set-url upstream https://github.com/wxWidgets/libjpeg-turbo.git
cd ../../..
cd wxWidgets/src/png
git remote set-url origin git@cpal.pw:~/libpng.git
git remote set-url upstream https://github.com/wxWidgets/libpng.git
cd ../../..
cd wxWidgets/src/tiff
git remote set-url origin git@cpal.pw:~/libtiff.git
git remote set-url upstream https://github.com/wxWidgets/libtiff.git
cd ../../..
cd wxWidgets/src/zlib
git remote set-url origin git@cpal.pw:~/zlib.git
git remote set-url upstream https://github.com/wxWidgets/zlib.git
cd ../../..
winConfigure.sh

41
docs/social_networking.md
View File

@ -264,6 +264,47 @@ So, you can navigate to whole world’s public conversation through
approved links and reply-to links – but not every spammer, scammer, and
shill in the world can fill your feed with garbage.
approved links and reply-to links – but not every spammer, scammer, and
shill in the world can fill your feed with garbage.
-## Algorithm and data structure.
-
-For this to work, the underlying structure needs to be something based on
-the same principles as Git and git repositories, except that Git relies on
-SSL and the Certificate Authority system to locate a repository, which
-dangerous centralization would fail under the inevitable attack. It needs to
-have instead for its repository name system a Kademlia distributed hash
-table within which local repositories find the network addresses of remote
-repositories on the basis of the public key of a Zooko identity of a person
-who pushed a tag or a branch to that repository, a branch being a thread,
-and the branch head in this case being the most recent response to a thread
-by a person you are following.
-
-So the hashes of identities are tracked by the distributed hash table, but the
-hashes of posts are not, because that would result in excessive numbers of
-lookups in a table that would very quickly hit its scaling limits. The hashes
-of posts are tracked by the repository of the feed that you are looking at, so
-require only local lookup, which is faster and less costly than a distributed
-lookup. This is equivalent to a fully distributed hash table where the key is
-not hash of post, but global name of area of interest, zooko nickname,
-zooko public key followed by his human readable thread name (branch
-name or tag name in git terminology) followed by hash of post, so that
-items that are likely to be looked up together are likely to be located
-physically close together on the same disk and will be sent along the same
-network connection.
-
-The messages of the people you are following are likely to be in a
-relatively small number of repositories, even if the total number of
-repositories out there is enormous and the number of hashes in each
-repository is enormous, so this algorithm and data structure will scale, and
-the responses to that thread that they have approved, by people you are not
-following, will be commits in that repository, that, by pushing their latest
-response to that thread to a public repository, they did the equivalent of a
-git commit and push to that repository.
-
-Each repository contains all the material the poster has approved, resulting
-in considerable duplication, but not enormous duplication.
-
The underlying protocol and mechanism is that when you are following
Bob, you get a Bob feed from a machine controlled by Bob, or controlled
by someone that Bob has chosen to act on his behalf, and that when Bob