[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141030080934.154ff729@recife.lan>
Date: Thu, 30 Oct 2014 08:09:34 -0200
From: Mauro Carvalho Chehab <mchehab@...radead.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Linus <torvalds@...ux-foundation.org>, linux-next@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: linux-next: unnecessary merges in the v4l-dvb tree
Hi Stephen,
Em Thu, 30 Oct 2014 09:24:45 +1100
Stephen Rothwell <sfr@...b.auug.org.au> escreveu:
> Hi Mauro,
>
> I noticed that you have two unnecessary merges in the v4l-dvb tree
> (git://linuxtv.org/mchehab/media-next.git#master). This is not
> entirely your fault. Unfortunately, when you do
>
> git merge <signed tag>
>
> git will produce a merge commit even if it could have fast
> forwarded :-(. Consequently, you have commits 1ef24960ab78 ("Merge tag
> 'v3.18-rc1' into patchwork") and d6d41ba1cb38 ("Merge remote-tracking
> branch 'linus/master' into patchwork") even though the patchwork branch
> in each case is included in the tag being merged.
>
> The only ways I know around this is to either merge the commit
> associated with the tag or do a (hard) reset to the tag.
A hard reset to the tag would likely be a bad idea, as it would break
the sub-maintainers trees that are based on my tree.
I generally use "git pull" for that, as the man page says that the
default behavior is to do fast forward:
"--ff
When the merge resolves as a fast-forward, only update
the branch pointer, without creating a merge commit.
This is the default behavior."
It seems that the man page is then outdated for signed tags, or,
eventually, we need to make --ff explicit on this case.
I'll try the approach of merging the associated commit next time,
but this is something that it is easy to forget.
>
> Linus, any thoughts?
Regards,
Mauro
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists