From 9210e8cdafb3fe674cabd8b78b462ba14bbc9f58 Mon Sep 17 00:00:00 2001 From: Cheng Date: Sun, 3 Jul 2022 08:53:53 +1000 Subject: [PATCH] Documented the painful process of moving a remote repository --- .gitmodules | 3 +++ docs/libraries.md | 45 ++++++++++++++++++++++++++++++++++++++++++++- wxWidgets | 2 +- 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/.gitmodules b/.gitmodules index 61e9099..b632f5a 100644 --- a/.gitmodules +++ b/.gitmodules @@ -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 \ No newline at end of file diff --git a/docs/libraries.md b/docs/libraries.md index 815fdd4..6636e93 100644 --- a/docs/libraries.md +++ b/docs/libraries.md @@ -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 diff --git a/wxWidgets b/wxWidgets index 5beff53..a8e46b7 160000 --- a/wxWidgets +++ b/wxWidgets @@ -1 +1 @@ -Subproject commit 5beff5392a2a760ef38a3a25b51db57c004a32cb +Subproject commit a8e46b7fdd0c3554bb4a55d729415c91c59d4cba