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

Documented the painful process of moving a remote repository

Browse Source
This commit is contained in:
Cheng 2022-07-03 08:53:53 +10:00
parent f4b761bed6
commit 9210e8cdaf
No known key found for this signature in database
GPG Key ID: D51301E176B31828
3 changed files with 48 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitmodules vendored
View File

@ -1,9 +1,12 @@
[submodule "libsodium"]
path = libsodium
url = git@rho.la:~/libsodium.git
branch = rho-fork
[submodule "mpir"]
path = mpir
url = git@rho.la:~/mpir.git
branch = rho-fork
[submodule "wxWidgets"]
path = wxWidgets
url = git@rho.la:~/wxWidgets.git
branch = rho-fork

45
docs/libraries.md
View File

@ -112,8 +112,51 @@ the submodule has to be in detached head mode, with the head pointing
directly to a commit, rather than pointing to a branch that points to a
commit.
You will import a submodule from someone else's project, but eventually you and your team are going to make minor changes to it to customize it to your project. In which case you will need your own remote team repo, in place of the original other team's repo.
Construct the copied remote repositories so that their default branch is your tracking branch, not the upstream branch.
``` bash
git init --bare -b «our_branch»
```
Then, in your local repository where you created the new branch, reset
the remote in your local repository to the new remote by editing `.gitconfig`
and push «our_branch» from your local in which you created your team's new
submodule branch to the remote.
or
``` bash
git clone --bare «their_remote» -b«their_stable_branch_or_release_tag»
cd «our_new_remote»
git symbolic-ref HEAD refs/heads/«our_new_branch»
```
If you fail to set your remote to your team's default branch, then your
local repositories will keep getting reset back to their team's branch, and
chaos ensues.
When moving the remote of a submodule in your local repository (usually from their team's remote to your team's remote) you update `.gitmodules` in your superproject, and in each submodule that has submodules of its own, then
```bash
git submodule update --init --recursive --force
git submodule foreach --recursive 'git status && git switch «our_branch» && git status && git remote -v && git switch --detach'
```
Your submodule remotes propagate from `.gitmodules` file of your superproject, and their branch propagates from the superproject *and* from the remote default branch.
And the branch will *also* propagate from `.gitmodules` if `branch = ...` is set.
Because git is a distributed archive, it is perfectly possible, and often
necessary, to work with all these set to different values, *provided* that
everyone is mindful that they are set to different values, and the
consequences and implications of them being set to different values. Which
consequences and implications get complicated, unobvious, difficult to
predict, and surprising when you are working with submodules.
Git commands in master project do not look inside the subproject. They
just look at the subproject's head.
just look at the subprojects head.
This means that signing off on changes to a submodule is irrelevant. One
signs off on the master project, which includes the hash of that submodule

2
wxWidgets

@ -1 +1 @@
Subproject commit 5beff5392a2a760ef38a3a25b51db57c004a32cb
Subproject commit a8e46b7fdd0c3554bb4a55d729415c91c59d4cba