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.
Linus, any thoughts?
--
Cheers,
Stephen Rothwell [email protected]
Hi Stephen,
Em Thu, 30 Oct 2014 09:24:45 +1100
Stephen Rothwell <[email protected]> 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
Hi Mauro,
On Thu, 30 Oct 2014 08:09:34 -0200 Mauro Carvalho Chehab <[email protected]> wrote:
>
> Em Thu, 30 Oct 2014 09:24:45 +1100
> Stephen Rothwell <[email protected]> escreveu:
>
> > 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 should have said that I don't expect you to change your tree at the
moment, just for that reason. But maybe next time.
> 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 think that --ff overrides this behaviour. Doing "git merge
'<tag>^{}'" works, but you can't use that with "git pull".
> I'll try the approach of merging the associated commit next time,
> but this is something that it is easy to forget.
I don't think it is a really big problem but it would be nicer for
everyone.
--
Cheers,
Stephen Rothwell [email protected]