Discussion: How to handle HALs, SDKs and libraries

[oss at c-mauderer.de]

Hello Karel,

Am 15.07.23 um 19:22 schrieb Karel Gardas:
> On 7/15/23 16:00, oss at c-mauderer.de wrote:
>> We should avoid rebasing and overwriting the old branch because we 
>> have to preserve a version that can be used with older RTEMS versions. 
>> So for rebasing, we would have to use multiple branches. Instead of 
>> rtems-6-branch, it could be a rtems-<date-of-base-revision> or 
>> something similar.
> 
> Thanks for confirmation. Have the same feeling about it.
> 
>> I think that depends heavily on how the upstream project works. If the 
>> upstream project uses a typical git workflow and is quite active, 
>> merging is most likely the better solution because we don't get big 
>> amounts of branches with that.
> 
> But this means we still merge to some rtems specific branch since master 
> is used to sync with upstream, right?
> 

Yes. That would be my suggested workflow: Track the upstream master or 
main branch and merge it into an RTEMS specific one.

>> On the other hand I know that some semiconductor manufacturers tend to 
>> just dump code into a repo and they don't care whether files move 
>> around or change heavily. They happily mix changes with reformatting 
>> the complete code. In that case you have no chance of a useful 
>> merge-commit. I think in these cases it's most likely better to create 
>> a new branch on every update and rebase the patches.
>>
>>>
>>> Anyway, still this is a branch based workflow. How would you do that 
>>> workflow with just fixed commit IDs?
>>>
>>> I'm asking since so far commit IDs on submodules were always obtain 
>>> from master branch which is what we basically fork and does not give 
>>> us ability to patch with RTEMS changes...
>>>
>>> So I'm curious how would you do that?
>>
>> I think I have put that in the wrong words. I assumed you mean that 
>> you want to use some feature that always uses the latest commit of a 
>> branch (also I don't know whether git even has that feature).
>>
>> What I wanted to say is that if I check out a RTEMS version from two 
>> months back, it should check out the revisions of the submodules that 
>> have been used in RTEMS two months back too. It must not use the 
>> latest HEAD of the branch from today. It's just part of having a 
>> version of the code that can be reproduced later.
> 
> Right! Now crucial question: is that even supported in git? I'm asking 
> since so far I've seen only:
> 
> - use fixed commit ids, but those are obtained only from master branch
> or
> - use branch and then this is always branch HEAD
> 
> I've not seen anything like "use fixed commit ID from branch XXX". So 
> question for you as an git expert: are you absolutely sure that this 
> workflow is supported by git at all? And by this I mean have you tested 
> that actually? :-)

I know only of the method that git uses a fixed commit ID in a 
submodule. It expects that the commit ID is on some branch in the remote 
repository. In my experience, it's not relevant whether the commit is on 
the branch `main`, `master`, `foo-bar`, `my-cool-new-feature` or any 
other branch. And yes: I use that regularly.

Additionally, git support adding an optional "branch" parameter to each 
submodule. But as far as I know, that is only used during

   git submodule update --remote

which basically tells git to pull the latest version of the branch 
instead of a special commit ID. I usually don't use that.

See https://stackoverflow.com/a/18797720 for a better explanation.

> 
>> Of course the revision from two months back has to be available in the 
>> repo. It doesn't really matter whether it's on master because the code 
>> just worked or whether it's a RTEMS specific branch because adaptions 
>> have been necessary.
> 
> You "it doesn't really matter" worries me a little bit. I'm not sure 
> this functionality is even supported hence my question above if you have 
> tested it yourself.

Yes, I use that regularly. For an (old) example, take a look at a branch 
in the repo that I use to test GSoC work:

   https://gitlab.com/c-mauderer/rtems-bbb/-/tree/6

I have a libs/rtems-libbsd submodule there that uses the revision 
c9474c0b which is on a cm/20200726_fix branch in my clone of 
rtems-libbsd. In the .gitmodules the branch is still set to "master". 
Despite that, git can find thre right commit ID.

Best regards

Christian

> 
> Thanks!
> Karel
>