Linus Torvalds writes: (Summary) wrote:
The reasoning is to avoid losing the signature from the tag (when merging a signed tag, the signature gets inserted into the merge commit itself - use "git log --show-signature" to see them). But, yes, that reasoning is really only valid for proper merges of new features, not for back-merges.
features, not for back-merges.
The problem, of course, is that since git is distributed, git doesn't know who is "upstream" and who is "downstream", so there's no _technical_ difference between merging a development tree, and a development tree doing a back-merge of the upstream tree.
[...]
signed tag (I forget the reasoning).The reasoning is to avoid losing the signature from the tag (when merging a signed tag, the signature gets inserted into the merge commit itself - use "git log --show-signature" to see them). But, yes, that reasoning is really only valid for proper merges of new features, not for back-merges.
features, not for back-merges.
The problem, of course, is that since git is distributed, git doesn't know who is "upstream" and who is "downstream", so there's no _technical_ difference between merging a development tree, and a development tree doing a back-merge of the upstream tree.