Slavek, all
After fixing the 3.5.13 source trees I had with:
git checkout v3.5.13-sru && git pull --rebase
I have missing dependencies. (basically all submodules that did not have a v3.5.13-sru branch were wiped out) Example:
On the 3.5.13 tree:
02:04 phoinix:/dat_f/tde/tde> l1 main/dependencies/ arts avahi-tqt dbus-1-tqt dbus-tqt qt3 tqtinterface
On R14:
02:14 phoinix:/dat_e/tde/tde> l1 main/dependencies/ arts avahi-tqt dbus-1-tqt dbus-tqt libart-lgpl libcaldav libcarddav python-tqt qt3 sip4-tqt tqca tqca-tls tqscintilla tqt3 tqtinterface
So basically libart-lgpl, libcaldav, libcarddav, python-tqt, sip4-tqt, tqca, tqca-tls, and tqscintilla were all dropped from the tree. (I'm sure I'm missing others under applications/ as well.
How do I pull all the remaining R14 sources/sub-modules into my new 3.5.13 tree? Do I have to do a manual diff of the directory structures and then do a manual "git checkout master -- <missing>" for each missing dir --or-- is there a better way to do it? The only other way I can think of would be to do a full git checkout master and covert the entire tree to master and then come back and switch submodules that have v3.5.13-sru branches back?
How do you suggest I fill in the 3.5.13 tree?
On 01/03/2014 02:44 AM, David C. Rankin wrote:
Slavek, all
After fixing the 3.5.13 source trees I had with:
git checkout v3.5.13-sru && git pull --rebase
I have missing dependencies. (basically all submodules that did not have a v3.5.13-sru branch were wiped out) Example:
On the 3.5.13 tree:
02:04 phoinix:/dat_f/tde/tde> l1 main/dependencies/ arts avahi-tqt dbus-1-tqt dbus-tqt qt3 tqtinterface
On R14:
02:14 phoinix:/dat_e/tde/tde> l1 main/dependencies/ arts avahi-tqt dbus-1-tqt dbus-tqt libart-lgpl libcaldav libcarddav python-tqt qt3 sip4-tqt tqca tqca-tls tqscintilla tqt3 tqtinterface
So basically libart-lgpl, libcaldav, libcarddav, python-tqt, sip4-tqt, tqca, tqca-tls, and tqscintilla were all dropped from the tree. (I'm sure I'm missing others under applications/ as well.
How do I pull all the remaining R14 sources/sub-modules into my new 3.5.13 tree? Do I have to do a manual diff of the directory structures and then do a manual "git checkout master -- <missing>" for each missing dir --or-- is there a better way to do it? The only other way I can think of would be to do a full git checkout master and covert the entire tree to master and then come back and switch submodules that have v3.5.13-sru branches back?
How do you suggest I fill in the 3.5.13 tree?
I think the problem is this:
16:27 phoinix:/dat_f/tde/tde> git checkout v3.5.13-sru -- scripts 16:27 phoinix:/dat_f/tde/tde/scripts> git branch -l experimental master * v3.5.13-sru
16:28 phoinix:/dat_f/tde/tde> git submodule init -- scripts 16:28 phoinix:/dat_f/tde/tde> git submodule update -- scripts Submodule path 'scripts': checked out '47fb38fad730f4fdfc21e6a89dea1c7a63bb0b71' 16:29 phoinix:/dat_f/tde/tde/scripts> git branch -l * (detached from 47fb38f) master v3.5.13-sru
If you ever run submodule update without immediately issuing a "git checkout <branch>" you will *detach* the submodule: (from man git-submodule)
<quote>
update Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. This will make the submodules HEAD be detached unless --rebase or --merge is specified or the key submodule.$name.update is set to rebase, merge or none. none can be overridden by specifying --checkout. Setting the key submodule.$name.update to !command will cause command to be run. command can be any arbitrary shell command that takes a single argument, namely the sha1 to update to. </quote>
The switch_all_submodules_to_head_and_clean script is the problem. When you issue:
git submodule update git submodule foreach "git checkout $branch && $THISSCRIPT $gituser"
it *ONLY* does 'foreach' for modules within the current branch. If the current toplevel branch is 'v3.5.13-sru' then all submodules that do NOT have a 'v3.5.13-sru' branch are not included in the foreach loop and are left *detached*. For example issuing:
git submodule foreach "git branch -r"
Does not list "main/dependencies/tqscintilla" because there is no v3.5.13-sru branch. Checking the status of main/dependencies/tqscintilla shows:
16:56 phoinix:/dat_f/tde/tde/main/dependencies/tqscintilla> git branch -l * (detached from 4285f9d) master
So git is very unhappy with the tree. Is there an easier way to fix this other than looping through all directories and doing an if git branch -r | grep -q sru; then git checkout v3.5.13-sru && git pull; else git checkout master && git pull; fi ??
On Friday 03 of January 2014 09:44:22 David C. Rankin wrote:
Slavek, all
After fixing the 3.5.13 source trees I had with:
git checkout v3.5.13-sru && git pull --rebase
I have missing dependencies. (basically all submodules that did not have a v3.5.13-sru branch were wiped out) Example:
On the 3.5.13 tree:
02:04 phoinix:/dat_f/tde/tde> l1 main/dependencies/ arts avahi-tqt dbus-1-tqt dbus-tqt qt3 tqtinterface
On R14:
02:14 phoinix:/dat_e/tde/tde> l1 main/dependencies/ arts avahi-tqt dbus-1-tqt dbus-tqt libart-lgpl libcaldav libcarddav python-tqt qt3 sip4-tqt tqca tqca-tls tqscintilla tqt3 tqtinterface
So basically libart-lgpl, libcaldav, libcarddav, python-tqt, sip4-tqt, tqca, tqca-tls, and tqscintilla were all dropped from the tree. (I'm sure I'm missing others under applications/ as well.
How do I pull all the remaining R14 sources/sub-modules into my new 3.5.13 tree? Do I have to do a manual diff of the directory structures and then do a manual "git checkout master -- <missing>" for each missing dir --or-- is there a better way to do it? The only other way I can think of would be to do a full git checkout master and covert the entire tree to master and then come back and switch submodules that have v3.5.13-sru branches back?
How do you suggest I fill in the 3.5.13 tree?
Sorry for the late reply.
Some git submodules are removed after switching meta-module 'tde' to v3.5.13-sru branch because they simply are not part of it.
For example python-tqt, sip4-tqt, tqca, tqca-tls and tqscintilla are designed for tqt3 while v3.5.13-sru branch uses qt3. Therefore these modules are not included in v3.5.13-sru branch. Exceptions are libart-lgpl, libcaldav and libcarddav. These, however, were included in the GIT later, and so lack the branch v3.5.13-sru. Similar is the case with some applications that have been added, but are prepared for R14 and do not have v3.5.13-sru branch.
Switching the meta-module 'tde' to v3.5.13-sru branch therefore behaves correctly - removes all submodules that are not part of v3.5.13-sru branch. Similarly, after switching meta-module 'tde' to the 'master' branch submodules will be again returned.
Slavek --
On 01/04/2014 11:21 AM, Slávek Banko wrote:
Sorry for the late reply.
Some git submodules are removed after switching meta-module 'tde' to v3.5.13-sru branch because they simply are not part of it.
For example python-tqt, sip4-tqt, tqca, tqca-tls and tqscintilla are designed for tqt3 while v3.5.13-sru branch uses qt3. Therefore these modules are not included in v3.5.13-sru branch. Exceptions are libart-lgpl, libcaldav and libcarddav. These, however, were included in the GIT later, and so lack the branch v3.5.13-sru. Similar is the case with some applications that have been added, but are prepared for R14 and do not have v3.5.13-sru branch.
Switching the meta-module 'tde' to v3.5.13-sru branch therefore behaves correctly - removes all submodules that are not part of v3.5.13-sru branch. Similarly, after switching meta-module 'tde' to the 'master' branch submodules will be again returned.
Slavek
Thanks Slavek,
I new what was happening, I just recall it behaving a bit differently a year ago. In the past, when I did a checkout of R14 and switched to sru, all of the R14 modules would remain. Now there is a sru branch for the toplevel of the tree where before there was not. Therefore, in the past when the submodule foreach was run, it would loop through all modules and they would be present in the tree. Now when submodule foreach is run the behavior is exactly how you describe it.
Attached is an old log from 2012 showing the branches available - now I understand (sort of..):