Discussion: How to handle HALs, SDKs and libraries

[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?

> 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? :-)

> 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.

Thanks!
Karel