Hello Karel,
Am 15.07.23 um 15:03 schrieb Karel Gardas:
On 7/15/23 14:33, o...@c-mauderer.de wrote:
I like submodules because they are well-supported by the usual tools.
Honestly. I like submodules idea, but hate its implementation. Some
reasons:
- submodules were added as a light weight feature and during the
development of git/submodule feature they accumulated some more.
- submodules started as way to get commit id of the external project
to the tree. But only master branch was supported. (not suitable for
RTEMS)
- later submodules added capability to use tag (still not suitable
for RTEMS)
- later submodules added capability to use different branch from the
project, but only a head of it. (finally what RTEMS need).
I don't like using branches instead of fixed commit IDs. Otherwise,
it's not possible to reliable re-build a fixed version.
And this is most important detail, so let's discuss this alone.
OK.
I have a hal library, let's consider this to be
https://github.com/karelfv/stm32h7xx_hal_driver -- just one project for
now.
This is a fork of ST Micro project of the same name which is a slow
development project. Few accumulated commits over one year let say.
This project needs few RTEMS related patches and there is a chance they
also need to kind of adapt to the new development. So let's branch as:
- master branch -- this is fork of ST Micro
- rtems-6-branch -- this is a branch from master at one point of time
accumulating RTEMS related changes.
Now, let's assume this was done 6 months ago and now you would like to
update from ST Micro upstream. How would you do that? I see:
- git fetch upstream inside the master
- git push master
that's update of master in fork and now:
- pull/merge master
or
- rebase master
in the rtems-6-branch? I'm afraid rebase is dangerous in shared setup so
probably pull/merge?
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.
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.
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.
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.
Best regards
Christian
Thanks!
Karel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
