forked from cheng/wallet
recovered some lost documentation
This commit is contained in:
parent
5364b3f770
commit
762cfa6f53
@ -95,7 +95,7 @@ Libraries are best dealt with as [Git submodules].
|
|||||||
|
|
||||||
[build libraries]:https://git-scm.com/book/en/v2/Git-Tools-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
|
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
|
modules simultaneously. But having your libraries separate from your git
|
||||||
repository results in non portable surprises and complexity. Makes it hard
|
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
|
communicate a particular project on the submodule to other people
|
||||||
working on that project as their master project.
|
working on that project as their master project.
|
||||||
|
|
||||||
Branch names are not useful within a submodule, though
|
Branch names within a submodule, though very useful when you working
|
||||||
submodule may well be, from the point of view of the primary
|
on a submodule, are not useful to the project as a whole, and except for the
|
||||||
developers, not a submodule but a module in its own right, used as
|
primary fork name, should be temporary and local., not pushed to the
|
||||||
a submodule in many different modules, so for them, branch names
|
project repository, But when you are modifying the submodules in a
|
||||||
will be useful. But when you are modifying the submodules in a
|
project as a single project, making related changes in the module and
|
||||||
project as a single project, making related changes in the module
|
submodule, the shared names that are common to all developers belong in
|
||||||
and submodule, the names belong in the primary project module,
|
the primary project module,and when you have done with a submodule,
|
||||||
Within the submodule, commits are nameless with detached head,
|
|
||||||
the name in primary module naming a group of related commits in
|
```bash
|
||||||
several submodules, which commits do not usually receive
|
git switch --detach
|
||||||
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.
|
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
|
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:
|
then:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
git submodule foreach --recursive 'git push origin HEAD:«your-tracking-branch»'
|
|
||||||
git submodule foreach --recursive 'git switch --detach'
|
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,
|
All of which, of course, presupposes you have already set unit tests,
|
||||||
upstream, origin, and your tracking branch appropriately.
|
upstream, origin, and your tracking branch appropriately.
|
||||||
|
|
||||||
Even if your local modifications are nameless in your local
|
Even if your local modifications are nameless in your local submodule
|
||||||
submodule repository, on your remote submodule repository they
|
repository, on your remote submodule repository they need to have a name
|
||||||
need to have a name to be pushed to, hence you need to have a
|
to be pushed to, hence you need to have a tracking branch in each of your
|
||||||
tracking branch in each of your remote images of each of your
|
remote images of each of your submodules, and that tracking branch will
|
||||||
submodules, and that tracking branch will need to point to the root
|
need to point to the root of a tree of all the nameless commits that the
|
||||||
of a tree of all the nameless commits that the names and commits
|
names and commits
|
||||||
in your superproject that contains this submodules point to.
|
in your superproject that contains this submodules point to.
|
||||||
|
|
||||||
You want `.gitmodules` in your local image of the repository to
|
You want `.gitmodules` in your local image of the repository to
|
||||||
|
@ -1,6 +1,12 @@
|
|||||||
body {
|
body {
|
||||||
max-width: 30em;
|
max-width: 30em;
|
||||||
margin-left: 1em;
|
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 {
|
table {
|
||||||
border-collapse: collapse;
|
border-collapse: collapse;
|
||||||
|
@ -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
|
Never check any Gpg key related to this project against a public
|
||||||
gpg key repository. It should not be there.
|
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
|
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
|
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
|
email of an enemy. We don't want Gpg used to link different email
|
||||||
|
52
docs/set_upstream.sh
Normal file
52
docs/set_upstream.sh
Normal 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
|
@ -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
|
approved links and reply-to links – but not every spammer, scammer, and
|
||||||
shill in the world can fill your feed with garbage.
|
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
|
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
|
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
|
by someone that Bob has chosen to act on his behalf, and that when Bob
|
||||||
|
Loading…
Reference in New Issue
Block a user