Re: Base 7.0.1.1 tag lost its submodule info

[Jeong Han Lee via Core-talk <core-talk@aps.anl.gov>]

Ralph, please don't say sorry, I am fine. Nothing happens. I also 
studied more about git itself.

I updated our building rule to handle 7.0.1.1 differently from others 
based on the Ralph's instruction. Our building rule can handle now as it 
was from 3.15.5, 3.15.6, 7.0.1.1, and 7.0.2.

Thank you for your work and support on them.

Best,
Han


On 1/31/19 10:49 AM, Ralph Lange via Core-talk wrote:
> 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
>     <http://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/
>     <http://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/
>     <http://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/
>     <http://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