From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Subject: Re: linux-next: unnecessary merge in the v4l-dvb tree Date: Mon, 12 Feb 2018 19:27:30 -0200 Message-ID: <20180212192730.4b4df411@vento.lan> References: <20180213080036.3bf3a908@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from osg.samsung.com ([64.30.133.232]:62825 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932104AbeBLV1h (ORCPT ); Mon, 12 Feb 2018 16:27:37 -0500 In-Reply-To: <20180213080036.3bf3a908@canb.auug.org.au> Sender: linux-next-owner@vger.kernel.org List-ID: To: Stephen Rothwell Cc: Linux-Next Mailing List , Linux Kernel Mailing List , Linus Hi Stephen, Em Tue, 13 Feb 2018 08:00:36 +1100 Stephen Rothwell 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