Hi Stephen, Em Tue, 13 Feb 2018 08:00:36 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> escreveu: > Hi Mauro, > > By merging the v4.16-rc1 tag into the v4l-dvb tree, you have created an > unnecessary merge commit. The v4l-dvb tree was already contained in > v4.16-rc1, so a fast forward merge was possible, but explicitly merging > a signed tag will give you a commit instead. In this case, you could > have just reset your branch to v4.16-rc1 or merged v4.16-rc1^0. I did the usual way I used to do in the past. Not sure why it ended by being an explicit merge instead of a fast forward. On a quick test here, doing: $ git checkout -b test media/v4.16-2 $ git merge v4.16-rc1 indeed makes produce a merging commit. I never realized that I could force a fast forward using the weird $ git merge v4.16-rc1^0 If this is the way we should do git merges, are there a way to make it default, suppressing the need of a "^0" (either via some .git/config parameter or changing at git code)? Doing just one such merge once or twice on every Kernel cycle, I'm pretty sure I'll forget to do it next time :-) > 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). Reset my tree on the top of v4.16-rc1 doesn't seem a good option, as it causes merge issues from media sub-maintainers and from other developer's trees. -- Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
