Merging tags does not fast-forward with git 1.7.9

Hi,

  with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.

The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.

Is there any simple and clear explanation for this? Thank you.

cheers,
Domenico

ps: I admit I didn't follow the details about tag signatures so probably
I missed something that I shouldn't.

On Thu, Feb 9, 2012 at 4:54 AM, Domenico Andreoli [off-list ref] wrote:

Hi,

 with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.

The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.

Is there any simple and clear explanation for this? Thank you.

Someone else can explain what is going on more fully, but can you
report what happens when you run "git merge --ff-only v3.X-rcY"?

-- 
-Dan

On Thu, Feb 09, 2012 at 10:50:50AM -0500, Dan Johnson wrote:

On Thu, Feb 9, 2012 at 4:54 AM, Domenico Andreoli [off-list ref] wrote:

quoted

  with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.

The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.

Is there any simple and clear explanation for this? Thank you.

Someone else can explain what is going on more fully, but can you
report what happens when you run "git merge --ff-only v3.X-rcY"?

This is Debian unstable, out-of-the-box git package 1.7.9-1.

$ git reset --hard v3.3-rc2
HEAD is now at 62aa2b5 Linux 3.3-rc2
$ git merge --ff-only v3.3-rc3
fatal: Not possible to fast-forward, aborting.
$ 

Same for v3.3-rc1 -> v3.3-rc2.

Thanks,
Domenico

On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:

Hi,

  with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.

The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.

Is there any simple and clear explanation for this? Thank you.

cheers,
Domenico

ps: I admit I didn't follow the details about tag signatures so probably
I missed something that I shouldn't.

This was discussed recently

http://thread.gmane.org/gmane.comp.version-control.git/189825

On Thu, Feb 09, 2012 at 05:06:41PM +0100, Carlos Martín Nieto wrote:

On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:

quoted

Hi,

  with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.

The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.

Is there any simple and clear explanation for this? Thank you.

cheers,
Domenico

ps: I admit I didn't follow the details about tag signatures so probably
I missed something that I shouldn't.

This was discussed recently

http://thread.gmane.org/gmane.comp.version-control.git/189825

The command I was looking for is:

  $ git merge --ff-only v3.X-rcY^0

thanks,
Domenico