Oolite Bulletins

I was brave enough to merge both PRs:
https://github.com/OoliteProject/oolite/pull/432
https://github.com/OoliteProject/oolite ... ies/pull/2

GitHub correctly triggered a rebuild, however when checking out the submodules I see this: However having merged that PR I'd expect the latest commit 0dacb28754e550ef56f15e4f9d3b69487a0a8e49 to be checked out.
So why is oolite still connected to the old commit, and more important: How can I change it?

hiran wrote: ↑Wed Jul 12, 2023 10:00 pm

However having merged that PR I'd expect the latest commit 0dacb28754e550ef56f15e4f9d3b69487a0a8e49 to be checked out.
So why is oolite still connected to the old commit, and more important: How can I change it?

Meanwhile I have played around and made the latest version work on my fork. Having verified it provides the intended changes, I ran another PR onto oolite master. Will test soon again.

Verified: the solution works, and I can see the intended behaviour.
Not that I really know how I got there and would be able to repeat it...

Something is not right here...

oolite-linux-dependencies points to a commit outside of the repository instead of its master.




Looks like it is pointing somewhere inside your fork.


To avoid complicating matters, I would suggest not committing anything more to oolite-linux-dependencies until this is resolved.

another_commander wrote: ↑Thu Jul 13, 2023 6:57 am

Something is not right here...

oolite-linux-dependencies points to a commit outside of the repository instead of its master.




Looks like it is pointing somewhere inside your fork.


To avoid complicating matters, I would suggest not committing anything more to oolite-linux-dependencies until this is resolved.

Uh, that was not intended. I will hold back further changes.
But how do we get this fixed? As stated above I was poking around. So I believe I can make the change undone - but then I'd be in the same mess as before where the scripts are unresponsive.

How can we get to a good state here?

I don't know what the network diagram is trying to tell us.
Looking from OoliteProject/oolite-linux-dependencies I see the picture you posted.
Looking from HiranChaudhuri/oolite-linux-dependencies I see a different picture. It shows the merged pull request.

Yet within a repository there should not be any links except we are talking submodules. So looking at OoliteProject/oolite, then deps/Linux-deps I see a commit, and clicking that I end up in OoliteProject/oolite-linux-dependencies - that is exactly where I'd expect it to point to.

Where exactly is the problem? Ok, I found the message And here is some explanation:
https://stackoverflow.com/questions/500 ... -no-branch

I take it that there is no name for this commit. Why so? I cannot tell. After all I am not even sure what I have done to get here.
But what I understand if we do not assign a tag or branch to that commit it may get removed by garbage collection.

So a fix would be to just assign a name. Is it ok if I call it 'master'?

Unless you know exactly what you are doing, I would advise against any further attempts at modifications.

The issue here is a detached HEAD of oolite-linux-dependencies, which is not a critical problem at this stage and should be fixable. The problem, if we want to call it that, is that it has introduced a reference to an external repository, which is out of our own control. If you decide one day, for whatever reason, to nuke your repository, oolite-linux-dependencies will lose its reference to that specific commit and I am not sure what happens in this case. So, although it is not something that is necessarily a devastating issue, it is indeed something that needs to be fixed, if anything for reasons of good repository organization.

I will try to fix it (without promising anything re the result) whenever I get a chance. This could well be after the weekend because RL obligations.

another_commander wrote: ↑Thu Jul 13, 2023 12:31 pm

I will try to fix it (without promising anything re the result) whenever I get a chance. This could well be after the weekend because RL obligations.

I will be patient. Thanks for spotting and diving in.

Here is what probably happened:

In the oolite-linux-deps repository I ran two commits based on the commit that used to be master. Only one of the two is the tip of master branch and that one correctly has the master branch attached. Nothing to worry about.

Yet, when bringing the oolite repository up to speed I was struggling for the correct way and eventually moved the submodule further. I could have picked 'master' yet wanted to nail it to a commit id just as it had been before. And during that battle I must have entered the other commit's id. So we end up with this diagram:



Proof:
Go to https://github.com/OoliteProject/oolite ... pendencies and you will see the master branch with commit 0dacb28, no warning is displayed.
Then go to https://github.com/OoliteProject/oolite ... aster/deps and click the Linux-deps link. You end up on the anonymous commit https://github.com/OoliteProject/oolite ... 8481620ad0. GitHub warns that this commit is not part of any branch. The pointer to "a fork outside the repo" is just a "may".

I believe all we have to do is one of
- point oolite's submodule to the commit 0dacb28
- move the tip of oolite-linux-deps:master to the referenced commit

It's fixed in commit d7a934b.

another_commander wrote: ↑Sun Jul 16, 2023 11:59 am

It's fixed in commit d7a934b.

Thank you.

What exactly did you do? How would I be able to point the main repo towards a desired commit?

hiran wrote: ↑Sun Jul 16, 2023 1:17 pm

What exactly did you do? How would I be able to point the main repo towards a desired commit?

I used the git command line. First I made sure that I was at the latest source revision on everything (git pull and then git submodule update) and that I was cd'ed to the deps/Linux-deps submodule root directory. In our case git rev-parse head was responding with the detached head commit we had before.

Next. all I had to do was git checkout master, which gave a warning that it would now be a good time to create a new branch if I wanted to keep the detached head's changes, which I promptly ignored. This retruned the Linux-deps tip to the latest master commit in the submodule (git rev-parse head was responding with 0dacb28).

Finally, back from Oolite's root source dir, I simply added the new submodule revision same way as I would normally add any other file:
git add deps/Linux-deps
git commit -m "Fixed detached head at Linux deps."
git push

Done.

another_commander wrote: ↑Sun Jul 16, 2023 2:07 pm

I used the git command line.
First ...
Next. ...
Finally, ...

Done.

Ok, the action seems quite easy if you know what you need to do. Thank you again for letting me know.