Hi Domenico,
Domenico Andreoli <cavok@debian.org> (2022-06-12):
> Therefore, when later a new upstream version is released, the `upstream`
> branch cannot fast forward to the new release tag but has to create
> a merge commit. The `upstream` is effectively a fork of the upstream
> branch just for the sake of tagging versions with such empty commits.
>
> What am I missing? :)
I think this is just regular Git when it's not told to apply special
care when it comes to merging tags. From `git help merge`:
MERGING TAG
When merging an annotated (and possibly signed) tag, Git always creates
a merge commit even if a fast-forward merge is possible, and the commit
message template is prepared with the tag message. Additionally, if the
tag is signed, the signature check is reported as a comment in the
message template. See also git-tag(1).
When you want to just integrate with the work leading to the commit
that happens to be tagged, e.g. synchronizing with an upstream release
point, you may not want to make an unnecessary merge commit.
In such a case, you can "unwrap" the tag yourself before feeding it to
git merge, or pass --ff-only when you do not have any work on your own.
e.g.
git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3
I don't have hard evidence on this (and don't feel like digging to
double check) but I seem to remember merging tags happily (getting a FF
without the aforementioned tricks) for many years, until “recently”. I'd
say that changed in buster or bullseye.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Attachment:
signature.asc
Description: PGP signature