History of Coding - github Initializing the Base

Always a good starting point, simply pull the base repository to a blank directory. In this case I've renamed the original /srv/website/bitweaver and am sitting at a command prompt in /srv/website.

git clone git@github.com:lsces/bitweaver.git

This starting point links to a number of submodules so the next step is to clone them as well. So one drops down into the main bitweaver directory and run.

git submodule update --init --recursive

A number of things failed here starting with references to missing entries in the .gitmodules file, but I could not initially work out where the problem was. Then I spotted that the new bitweaver directory had subdirectories for packages I did not plan to worry about initially. So the next step was to cull those entries for the time being.

And this continued to remove all the secondary stuff I did not want to have to worry about yet. Many may be added back later. Once tidied, this needs pushing to github

Then the submodule init command can be repeated ... and the next set of directories sorted. I did come unstuck with the kernel/adodb folder as this is not in bitweaver, it was part of the kernel repository and so I needed to decent into that and repeat the process on just 'adodb'. Not sure why all of this is needed but one has to update the submodule and then the wrapper.

Always a good starting point, simply pull the base repository to a blank directory. In this case I've renamed the original /srv/website/bitweaver and am sitting at a command prompt in /srv/website.

But even that can be wrong if the repository has not be built properly ( ((Coding - Pass 1|Pass 1 is Here)) ). First it assumes the user already has ssh access set up to github which may not be the case, so  https://github.com/lsces/bitweaver.git is a better starting point. But at the moment even this will not work as my version of the master repository is rather incomplete and messy. So I need to document building the right base before actually trying to use it. This starting point links to a number of submodules so the next step would be to clone them as well. So one drops down into the main bitweaver directory and runs.

Once I have everything packaged right this might actually work, but two things have to happen. First I need all of the submodules present in the .git bitweaver repository, and the 'advise' from Mistral on doing this was less than accurate! Second is ensuring the right version is returned which I'll ignore for the moment, but as long as I tag the updates properly that should be less of a problem. So what IS the correct procedure to pull a new submodule into the code base? Start by adding the submodule to .gitmodules ( although I think git will do this anyway? ) 

Again not sure if both lines are necessary, need to check again, but documenting what worked to date. Esentially we are downloading the code set to folder submodule. Worth flagging that the external packages have a format external/submodule which is where I have adodb and smarty currently.

Then the submodule init command can be repeated ... and any errors can be sorted. Just which version is downloaded it the question, and hopefully it will be the right one for the release that has been selected. VSCode allows checking just what build is being used and to date I have been having to manual reset things after using 'submodule update', but one can manually select the right version using.

Currently I do now have a list of submodules that matches what I expect and after some fun I can get back to updating the blogs and fisheye code to match the running software. The following command shows the active list, but I am not quite sure about the version tags it returns. Some I do recognise but others a old ones.

Once completed the submodule init command ran clean and everything seems to be in the right place. At least that is where I am at this moment while I try and decide on the next step. I think I need a branch on lsces/bitweaver and then build the new fork on that branch?

I've not actually tested the following yet, but some of it I had used while trying to find out where, for example, fisheye had disappeared to. That it turned out was down to git@github.com not allowing access, while the 443 version worked fine, as does the https:// one.

Much of the help I have been getting in using git has been via duck.ai and Mistral Small 3 chatbot. I've commented on it's accuracy in the blogs and the help has at times been less than productive. The key step 'git submodule add ' was missing until late in the thread! Yet it is key, and on now checking it DOES update the record in .gitmodules, so all of the directions to do this manually were simply wrong. The crib sheet above I am now sure can be much simplified now that I know where to look for the accurate usage instructions.