Re: Base 7.0.1.1 tag lost its submodule info

[Ralph Lange via Core-talk <core-talk@aps.anl.gov>]

Sorry Han,

There are some particular issues with how git handles (or actually doesn't) checkouts of submodules from the parent module itself, which was one of the reasons to eventually get rid of that setup.

Inside the .gitmodules file, a repository setting of './' (i.e. the parent) is silently translated into the remote URL of the parent repository, so the whole idea of checking out multiple branches from the single local repo is being perverted into cloning multiple copies of the same remote repo, wasting space intead of saving it.

The workaround is to not let git automatically do the submodule init for these three "internal" branches. This has always been that way, I have always been doing this for all my working copies. With that manual local clone of the internal branches, there really is only one copy of the repository on disk.

Here's my log - using ssh for the epics-base module to demonstrate that it also works (my input is bold):

ralph@debian-testing:~$ mkdir TTT; cd TTT

ralph@debian-testing:~/TTT$ git clone -b R7.0.1.1 ssh://git@github.com/epics-base/epics-base.git base-7.0.1.1

Cloning into 'base-7.0.1.1'...

remote: Enumerating objects: 1, done.

remote: Counting objects: 100% (1/1), done.

remote: Total 119076 (delta 0), reused 0 (delta 0), pack-reused 119075

Receiving objects: 100% (119076/119076), 99.26 MiB | 756.00 KiB/s, done.

Resolving deltas: 100% (87164/87164), done.

Note: checking out '37d103f9cd8b05f97bdbd1e26353102e33231960'.

You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

ralph@debian-testing:~/TTT$ cd base-7.0.1.1/

ralph@debian-testing:~/TTT/base-7.0.1.1$ git clone . modules/ca

Cloning into 'modules/ca'...

done.

Note: checking out '37d103f9cd8b05f97bdbd1e26353102e33231960'.

You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

ralph@debian-testing:~/TTT/base-7.0.1.1$ git clone . modules/database

Cloning into 'modules/database'...

done.

Note: checking out '37d103f9cd8b05f97bdbd1e26353102e33231960'.

You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

ralph@debian-testing:~/TTT/base-7.0.1.1$ git clone . modules/libcom

Cloning into 'modules/libcom'...

done.

Note: checking out '37d103f9cd8b05f97bdbd1e26353102e33231960'.

You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

ralph@debian-testing:~/TTT/base-7.0.1.1$ git submodule update --init

Submodule 'modules/ca' (ssh://git@github.com/epics-base/epics-base.git/) registered for path 'modules/ca'

Submodule 'modules/database' (ssh://git@github.com/epics-base/epics-base.git/) registered for path 'modules/database'

Submodule 'modules/libcom' (ssh://git@github.com/epics-base/epics-base.git/) registered for path 'modules/libcom'

Submodule 'modules/normativeTypes' (https://github.com/epics-base/normativeTypesCPP) registered for path 'modules/normativeTypes'

Submodule 'modules/pvAccess' (https://github.com/epics-base/pvAccessCPP) registered for path 'modules/pvAccess'

Submodule 'modules/pvData' (https://github.com/epics-base/pvDataCPP) registered for path 'modules/pvData'

Submodule 'modules/pvDatabase' (https://github.com/epics-base/pvDatabaseCPP) registered for path 'modules/pvDatabase'

Submodule 'modules/pva2pva' (https://github.com/epics-base/pva2pva) registered for path 'modules/pva2pva'

Submodule 'modules/pvaClient' (https://github.com/epics-base/pvaClientCPP) registered for path 'modules/pvaClient'

Cloning into '/home/ralph/TTT/base-7.0.1.1/modules/normativeTypes'...

Cloning into '/home/ralph/TTT/base-7.0.1.1/modules/pvAccess'...

Cloning into '/home/ralph/TTT/base-7.0.1.1/modules/pvData'...

Cloning into '/home/ralph/TTT/base-7.0.1.1/modules/pvDatabase'...

Cloning into '/home/ralph/TTT/base-7.0.1.1/modules/pva2pva'...

Cloning into '/home/ralph/TTT/base-7.0.1.1/modules/pvaClient'...

Submodule path 'modules/ca': checked out '524ceee2c8ce8f8446c46d93b5a467edd14b8cc5'

Submodule path 'modules/database': checked out '610f008529059c7fc1e35896ff0f678b7adcfa6d'

Submodule path 'modules/libcom': checked out '8ce980f6637d85fb1f5a139bab404269734b31bc'

Submodule path 'modules/normativeTypes': checked out 'ba2e1c8a1d1837c8817e14372cccc12f16942200'

Submodule path 'modules/pvAccess': checked out '8c4353bd57dc4e29145792b2b6e2aeeb81c32efe'

Submodule path 'modules/pvData': checked out '07afe3887bc4d6ca921d135eef13d91c9e84a155'

Submodule path 'modules/pvDatabase': checked out 'b26c0ecd713a9c87b891afbfef44d6109e13800a'

Submodule path 'modules/pva2pva': checked out '40014786810c3709c0e14cb179c93cdcfb66f973'

Submodule path 'modules/pvaClient': checked out 'b5291d96196825fd2ce5d7ce47559b1dddf3449e'

ralph@debian-testing:~/TTT/base-7.0.1.1$  

So - once you navigate around Git's unwanted behavior - the rest of the process is completely based on the hashes - that are permanent - and does not rely on volatile branch names.

The past has not been changed, no tags have been touched, all original commits are wherever they have been.

In general, I would suggest that you always apply known patches for bugs you find and don't let this keep you from updating.

Looking at 7.0.1.1 and 7.0.2, you deliberately use a version with lower overall quality (more bugs) to avoid applying a critical bugfix patch.

Cheers,
~Ralph