Can't squash merge with merge.ff set to false

Can't squash merge with merge.ff set to false

[Robert Dailey]

Not sure if this is intended or a bug, but with the following configuration:

$ git config --global merge.ff false

I am not able to merge my topic branch into master with squash option:

$ git checkout master
$ git merge --squash topic
fatal: You cannot combine --squash with --no-ff.

I'm not sure why a non-fast-forward merge would prevent a squash
merge, since by its very nature a squashed merge is not a fast forward
merge (or maybe it is if you only have one commit).

Is there an issue here? I like fast forward merges to be off by
default, since I want to control when they happen. Most of my merges
do not use --squash, so I'm catering to the common case.

Need advice on how to get past this issue. Thanks in advance.

Re: Can't squash merge with merge.ff set to false

[Bryan Turner]

On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
> Not sure if this is intended or a bug, but with the following configuration:
>
> $ git config --global merge.ff false
>
> I am not able to merge my topic branch into master with squash option:
>
> $ git checkout master
> $ git merge --squash topic
> fatal: You cannot combine --squash with --no-ff.
>
> I'm not sure why a non-fast-forward merge would prevent a squash
> merge, since by its very nature a squashed merge is not a fast forward
> merge (or maybe it is if you only have one commit).
>
> Is there an issue here? I like fast forward merges to be off by
> default, since I want to control when they happen. Most of my merges
> do not use --squash, so I'm catering to the common case.
>
> Need advice on how to get past this issue. Thanks in advance.

The easiest way to move forward is probably to pass "--ff" on the
command line to override the config, when you're using "--squash".

As for why the two aren't allowed together, my assumption would be
because if you're only squashing a single commit "--squash" and that
commit is fast-forward from the target, a new commit is not created
and instead the target branch is fast-forwarded. With "--no-ff", it's
questionable what "--squash" should do in that case. Fast-forward
anyway? Rewrite the commit simply to get new committer details and
SHA-1?

Hope this helps!
Bryan Turner

Re: Can't squash merge with merge.ff set to false

[Paul Smith]

On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
> > Not sure if this is intended or a bug, but with the following
> > configuration:
> > 
> > $ git config --global merge.ff false
> > 
> > I am not able to merge my topic branch into master with squash
> > option:
> > 
> > $ git checkout master
> > $ git merge --squash topic
> > fatal: You cannot combine --squash with --no-ff.
> > 
> > I'm not sure why a non-fast-forward merge would prevent a squash
> > merge, since by its very nature a squashed merge is not a fast
> > forward merge (or maybe it is if you only have one commit).

Hah!  I was just thinking of checking the latest Git RC I built
yesterday to see if this pet peeve of mine has been fixed yet.  I guess
not!

> The easiest way to move forward is probably to pass "--ff" on the
> command line to override the config, when you're using "--squash".

That's what we always have to do.  Very annoying; we use squash-merge
extensively but also want to require ff merge by default.

> As for why the two aren't allowed together, my assumption would be
> because if you're only squashing a single commit "--squash" and that
> commit is fast-forward from the target, a new commit is not created
> and instead the target branch is fast-forwarded. With "--no-ff", it's
> questionable what "--squash" should do in that case. Fast-forward
> anyway? Rewrite the commit simply to get new committer details and
> SHA-1?

If it only failed when you were squash-merging a single commit that was
also fast-forwardable, I guess that would be one thing.  But even if I
have multiple commits and I want to squash-merge them, which clearly is
a separate operation giving different results, I get this error.

I don't think Git should try to be clever here (if that's what it's
doing--I always assumed it was just a missing configuration case in the
error check).  If I asked for a squash-merge then Git should give me a
squash merge.

So in answer to your question, --squash should give me a squash merge
and the setting of --ff / --no-ff should be completely ignored, as it's
irrelevant.

My $0.02.

Re: Can't squash merge with merge.ff set to false

[Robert Dailey]

On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith <paul@mad-scientist.net> wrote:
> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
>> > Not sure if this is intended or a bug, but with the following
>> > configuration:
>> >
>> > $ git config --global merge.ff false
>> >
>> > I am not able to merge my topic branch into master with squash
>> > option:
>> >
>> > $ git checkout master
>> > $ git merge --squash topic
>> > fatal: You cannot combine --squash with --no-ff.
>> >
>> > I'm not sure why a non-fast-forward merge would prevent a squash
>> > merge, since by its very nature a squashed merge is not a fast
>> > forward merge (or maybe it is if you only have one commit).
>
> Hah!  I was just thinking of checking the latest Git RC I built
> yesterday to see if this pet peeve of mine has been fixed yet.  I guess
> not!
>
>> The easiest way to move forward is probably to pass "--ff" on the
>> command line to override the config, when you're using "--squash".
>
> That's what we always have to do.  Very annoying; we use squash-merge
> extensively but also want to require ff merge by default.
>
>> As for why the two aren't allowed together, my assumption would be
>> because if you're only squashing a single commit "--squash" and that
>> commit is fast-forward from the target, a new commit is not created
>> and instead the target branch is fast-forwarded. With "--no-ff", it's
>> questionable what "--squash" should do in that case. Fast-forward
>> anyway? Rewrite the commit simply to get new committer details and
>> SHA-1?
>
> If it only failed when you were squash-merging a single commit that was
> also fast-forwardable, I guess that would be one thing.  But even if I
> have multiple commits and I want to squash-merge them, which clearly is
> a separate operation giving different results, I get this error.
>
> I don't think Git should try to be clever here (if that's what it's
> doing--I always assumed it was just a missing configuration case in the
> error check).  If I asked for a squash-merge then Git should give me a
> squash merge.
>
> So in answer to your question, --squash should give me a squash merge
> and the setting of --ff / --no-ff should be completely ignored, as it's
> irrelevant.
>
> My $0.02.

Seems like --ff works, but is also misleading since in my case (more
than one commit) I'm not doing a ff merge and there's no possibility
of it. I think your idea of the 2 being distinctly separate makes
sense. Basically, --squash takes precedence and if the mechanism to
implement squash in certain scenarios (such as single commit) is
fast-forward merge, then that decision is made for the user and is no
longer something they can control.

Re: Can't squash merge with merge.ff set to false

[Bryan Turner]

On Fri, Jan 5, 2018 at 12:35 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
> On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith <paul@mad-scientist.net> wrote:
>> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
>>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:
>>>
>>> As for why the two aren't allowed together, my assumption would be
>>> because if you're only squashing a single commit "--squash" and that
>>> commit is fast-forward from the target, a new commit is not created
>>> and instead the target branch is fast-forwarded. With "--no-ff", it's
>>> questionable what "--squash" should do in that case. Fast-forward
>>> anyway? Rewrite the commit simply to get new committer details and
>>> SHA-1?
>>
>> If it only failed when you were squash-merging a single commit that was
>> also fast-forwardable, I guess that would be one thing.  But even if I
>> have multiple commits and I want to squash-merge them, which clearly is
>> a separate operation giving different results, I get this error.

I think there's a reasonable argument that having the failure be
consistent is easier to reason about, and therefore provides a
"better" user experience (to some definition of "better" which all
people may not share in common).

If the failure was delayed until "git merge --squash" decided it
wanted to fast-forward, the failure might seem more arbitrary.

>>
>> I don't think Git should try to be clever here (if that's what it's
>> doing--I always assumed it was just a missing configuration case in the
>> error check).  If I asked for a squash-merge then Git should give me a
>> squash merge.
>>
>> So in answer to your question, --squash should give me a squash merge
>> and the setting of --ff / --no-ff should be completely ignored, as it's
>> irrelevant.
>>
>> My $0.02.
>
> Seems like --ff works, but is also misleading since in my case (more
> than one commit) I'm not doing a ff merge and there's no possibility
> of it.

"--ff" doesn't say "git merge" _must_ fast-forward ("--ff-only"); it
says that it _can_. At a general level with "--squash", that seems to
be exactly correct. A "--squash" merge can create a new commit, or it
can fast-forward an existing commit if the situation allows. Based on
that, passing "--ff" doesn't seem misleading to me.

> I think your idea of the 2 being distinctly separate makes
> sense. Basically, --squash takes precedence and if the mechanism to
> implement squash in certain scenarios (such as single commit) is
> fast-forward merge, then that decision is made for the user and is no
> longer something they can control.

The two _aren't_ distinctly separate, though. "git merge --squash
--ff-only" has very different semantics to "git merge --squash --ff",
in that it will only create a new squashed commit (or fast-forward a
single commit) if the incoming commit(s) are fast-forward from the
target. So there _is_ a setting for the fast-forward mode (given
"--ff", "--ff-only", and "--no-ff" are a tri-state switch, and
therefore comprise a single setting) that does impact squashing.

Re: Can't squash merge with merge.ff set to false

[Robert Dailey]

On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner <bturner@atlassian.com> wrote:
> The two _aren't_ distinctly separate, though. "git merge --squash
> --ff-only" has very different semantics to "git merge --squash --ff",
> in that it will only create a new squashed commit (or fast-forward a
> single commit) if the incoming commit(s) are fast-forward from the
> target. So there _is_ a setting for the fast-forward mode (given
> "--ff", "--ff-only", and "--no-ff" are a tri-state switch, and
> therefore comprise a single setting) that does impact squashing.

That feels really contrived to me though. For example, when I'm asking
to squash I don't really care about fast forward in that case.
Squashing means I'm expecting a possibly completely new commit with my
collective changes. If I only had one commit on my branch, likely I'd
be aware of that, and would do a fast forward merge or something. I
think the difference here is mind set. And maybe this is just me, but
the mentality when I choose --squash means I want nothing to do with
fast-foward. I don't care about it affecting the operation. If a
fast-foward happens to be the end result, I still don't care. Git made
that decision for me. And all I want is the end result: A single
commit.

Re: Can't squash merge with merge.ff set to false

[Jonathan Nieder]

Hi,

Robert Dailey wrote:

> Not sure if this is intended or a bug, but with the following configuration:
>
> $ git config --global merge.ff false
>
> I am not able to merge my topic branch into master with squash option:
>
> $ git checkout master
> $ git merge --squash topic
> fatal: You cannot combine --squash with --no-ff.

I see two issues here:

 1. The check and error message really only make sense when you passed
    --no-ff directly, not implicitly using config.  The problem you
    are running into was presumably introduced when merge.ff was added
    in v1.7.6-rc0~67^2~1 (2011-05-06).

 2. Whether it comes from an alias or config, --no-ff and --squash are
    not fundamentally incompatible.  --no-ff says not to do something
    and --squash says to do a different thing, so --squash should win.

So I suspect that making --squash override --no-ff would be a
reasonable behavior.

Care to write a patch?

Thanks,
Jonathan