Hello Karel,
Am 15.07.23 um 19:22 schrieb Karel Gardas:
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?
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
