On Mon, Feb 12, 2018 at 1:00 PM, Stephen Rothwell [off-list ref] wrote:
Linus, this happens a bit after the merge window, so I am wondering
about the rational of not doing a fast forward merge when merging a
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).
So when I merge a signed tag, I do *not* want to fast-forward to the
top commit, because then I'd lose the signature from the tag. Thus the
"merging signed tags are non-fast-forward by default" reasoning.
But, yes, that reasoning is really only valid for proper merges of new
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.
Maybe it was a mistake to make signed tag merges non-fast-forward,
since they cause these kinds of issues with people who use "pull" to
update their otherwise unmodified trees.
I can always teach myself to just use --no-ff, since I end up doing
things like verifying at the signatures anyway.
Junio, comments?
Linus
Em Mon, 12 Feb 2018 13:15:04 -0800
Linus Torvalds [off-list ref] escreveu:
On Mon, Feb 12, 2018 at 1:00 PM, Stephen Rothwell [off-list ref] wrote:
quoted
Linus, this happens a bit after the merge window, so I am wondering
about the rational of not doing a fast forward merge when merging a
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).
So when I merge a signed tag, I do *not* want to fast-forward to the
top commit, because then I'd lose the signature from the tag. Thus the
"merging signed tags are non-fast-forward by default" reasoning.
But, yes, that reasoning is really only valid for proper merges of new
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.
Maybe it was a mistake to make signed tag merges non-fast-forward,
since they cause these kinds of issues with people who use "pull" to
update their otherwise unmodified trees.
I can always teach myself to just use --no-ff, since I end up doing
things like verifying at the signatures anyway.
Hmm... at least at git version 2.14.3, git documentation doesn't
mention that signed pull requests won't do fast forward. Instead,
it says that --ff is the default behavior:
--ff
When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the
default behavior.
Btw, even doing:
$ git merge -ff v4.16-rc1
it will still produce a git commit for the merge.
--
Thanks,
Mauro
On Mon, Feb 12, 2018 at 1:15 PM, Linus Torvalds
[off-list ref] 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).
I think the commit that actually introduced the behavior was
fab47d057: merge: force edit and no-ff mode when merging a tag object
back in 2011, so we've had this behavior for a long time. So it's
probably not be worth tweaking the behavior any more, and maybe we
need to educate people to not update to other peoples state with "git
pull".
Maybe we could just tell people to have something like
git config --global alias.update pull --ff-only
and use that for "try to update to upstream".
Linus