On 7/15/23 16:00, o...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
