{"thread":{"id":"47545","subject":"Can't squash merge with merge.ff set to false","startedAt":"2018-01-05T19:59:32Z","lastAt":"2018-01-06T00:11:59Z","messageCount":7,"participants":["Robert Dailey","Bryan Turner","Paul Smith","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"335951","messageId":"CAHd499C=3Y-ykgYZhSJzk=e-Pi6BUFeN8C89krd5T7T5fRB91g@mail.gmail.com","threadId":"47545","inReplyTo":null,"subject":"Can't squash merge with merge.ff set to false","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2018-01-05T19:59:25Z","receivedAt":"2018-01-05T19:59:32Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"Not sure if this is intended or a bug, but with the following configuration:\n\n$ git config --global merge.ff false\n\nI am not able to merge my topic branch into master with squash option:\n\n$ git checkout master\n$ git merge --squash topic\nfatal: You cannot combine --squash with --no-ff.\n\nI'm not sure why a non-fast-forward merge would prevent a squash\nmerge, since by its very nature a squashed merge is not a fast forward\nmerge (or maybe it is if you only have one commit).\n\nIs there an issue here? I like fast forward merges to be off by\ndefault, since I want to control when they happen. Most of my merges\ndo not use --squash, so I'm catering to the common case.\n\nNeed advice on how to get past this issue. Thanks in advance.\n"},{"id":"335958","messageId":"CAGyf7-FHyO9pkEFFguea+B+VMTodF=mg8wJNedvjYdL7e7ORqQ@mail.gmail.com","threadId":"47545","inReplyTo":"CAHd499C=3Y-ykgYZhSJzk=e-Pi6BUFeN8C89krd5T7T5fRB91g@mail.gmail.com","subject":"Re: Can't squash merge with merge.ff set to false","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2018-01-05T20:12:27Z","receivedAt":"2018-01-05T20:12:33Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey wrote:\n> Not sure if this is intended or a bug, but with the following configuration:\n>\n> $ git config --global merge.ff false\n>\n> I am not able to merge my topic branch into master with squash option:\n>\n> $ git checkout master\n> $ git merge --squash topic\n> fatal: You cannot combine --squash with --no-ff.\n>\n> I'm not sure why a non-fast-forward merge would prevent a squash\n> merge, since by its very nature a squashed merge is not a fast forward\n> merge (or maybe it is if you only have one commit).\n>\n> Is there an issue here? I like fast forward merges to be off by\n> default, since I want to control when they happen. Most of my merges\n> do not use --squash, so I'm catering to the common case.\n>\n> Need advice on how to get past this issue. Thanks in advance.\n\nThe easiest way to move forward is probably to pass \"--ff\" on the\ncommand line to override the config, when you're using \"--squash\".\n\nAs for why the two aren't allowed together, my assumption would be\nbecause if you're only squashing a single commit \"--squash\" and that\ncommit is fast-forward from the target, a new commit is not created\nand instead the target branch is fast-forwarded. With \"--no-ff\", it's\nquestionable what \"--squash\" should do in that case. Fast-forward\nanyway? Rewrite the commit simply to get new committer details and\nSHA-1?\n\nHope this helps!\nBryan Turner\n"},{"id":"336003","messageId":"CAHd499A_ANzFA8HSQLJWakzzWanbmVGnur=um=kquYHu0aCBcQ@mail.gmail.com","threadId":"47545","inReplyTo":"1515183976.21764.114.camel@mad-scientist.net","subject":"Re: Can't squash merge with merge.ff set to false","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2018-01-05T20:35:59Z","receivedAt":"2018-01-05T20:36:05Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith wrote:\n> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:\n>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey wrote:\n>> > Not sure if this is intended or a bug, but with the following\n>> > configuration:\n>> >\n>> > $ git config --global merge.ff false\n>> >\n>> > I am not able to merge my topic branch into master with squash\n>> > option:\n>> >\n>> > $ git checkout master\n>> > $ git merge --squash topic\n>> > fatal: You cannot combine --squash with --no-ff.\n>> >\n>> > I'm not sure why a non-fast-forward merge would prevent a squash\n>> > merge, since by its very nature a squashed merge is not a fast\n>> > forward merge (or maybe it is if you only have one commit).\n>\n> Hah! I was just thinking of checking the latest Git RC I built\n> yesterday to see if this pet peeve of mine has been fixed yet. I guess\n> not!\n>\n>> The easiest way to move forward is probably to pass \"--ff\" on the\n>> command line to override the config, when you're using \"--squash\".\n>\n> That's what we always have to do. Very annoying; we use squash-merge\n> extensively but also want to require ff merge by default.\n>\n>> As for why the two aren't allowed together, my assumption would be\n>> because if you're only squashing a single commit \"--squash\" and that\n>> commit is fast-forward from the target, a new commit is not created\n>> and instead the target branch is fast-forwarded. With \"--no-ff\", it's\n>> questionable what \"--squash\" should do in that case. Fast-forward\n>> anyway? Rewrite the commit simply to get new committer details and\n>> SHA-1?\n>\n> If it only failed when you were squash-merging a single commit that was\n> also fast-forwardable, I guess that would be one thing. But even if I\n> have multiple commits and I want to squash-merge them, which clearly is\n> a separate operation giving different results, I get this error.\n>\n> I don't think Git should try to be clever here (if that's what it's\n> doing--I always assumed it was just a missing configuration case in the\n> error check). If I asked for a squash-merge then Git should give me a\n> squash merge.\n>\n> So in answer to your question, --squash should give me a squash merge\n> and the setting of --ff / --no-ff should be completely ignored, as it's\n> irrelevant.\n>\n> My $0.02.\n\nSeems like --ff works, but is also misleading since in my case (more\nthan one commit) I'm not doing a ff merge and there's no possibility\nof it. I think your idea of the 2 being distinctly separate makes\nsense. Basically, --squash takes precedence and if the mechanism to\nimplement squash in certain scenarios (such as single commit) is\nfast-forward merge, then that decision is made for the user and is no\nlonger something they can control.\n"},{"id":"336009","messageId":"CAGyf7-E-7KUCAM8SeG-2powp2XN+H=16VG-6XBmj1wUT9tjVcw@mail.gmail.com","threadId":"47545","inReplyTo":"CAHd499A_ANzFA8HSQLJWakzzWanbmVGnur=um=kquYHu0aCBcQ@mail.gmail.com","subject":"Re: Can't squash merge with merge.ff set to false","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2018-01-05T20:54:34Z","receivedAt":"2018-01-05T20:54:44Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Fri, Jan 5, 2018 at 12:35 PM, Robert Dailey wrote:\n> On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith wrote:\n>> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:\n>>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey wrote:\n>>>\n>>> As for why the two aren't allowed together, my assumption would be\n>>> because if you're only squashing a single commit \"--squash\" and that\n>>> commit is fast-forward from the target, a new commit is not created\n>>> and instead the target branch is fast-forwarded. With \"--no-ff\", it's\n>>> questionable what \"--squash\" should do in that case. Fast-forward\n>>> anyway? Rewrite the commit simply to get new committer details and\n>>> SHA-1?\n>>\n>> If it only failed when you were squash-merging a single commit that was\n>> also fast-forwardable, I guess that would be one thing. But even if I\n>> have multiple commits and I want to squash-merge them, which clearly is\n>> a separate operation giving different results, I get this error.\n\nI think there's a reasonable argument that having the failure be\nconsistent is easier to reason about, and therefore provides a\n\"better\" user experience (to some definition of \"better\" which all\npeople may not share in common).\n\nIf the failure was delayed until \"git merge --squash\" decided it\nwanted to fast-forward, the failure might seem more arbitrary.\n\n>>\n>> I don't think Git should try to be clever here (if that's what it's\n>> doing--I always assumed it was just a missing configuration case in the\n>> error check). If I asked for a squash-merge then Git should give me a\n>> squash merge.\n>>\n>> So in answer to your question, --squash should give me a squash merge\n>> and the setting of --ff / --no-ff should be completely ignored, as it's\n>> irrelevant.\n>>\n>> My $0.02.\n>\n> Seems like --ff works, but is also misleading since in my case (more\n> than one commit) I'm not doing a ff merge and there's no possibility\n> of it.\n\n\"--ff\" doesn't say \"git merge\" _must_ fast-forward (\"--ff-only\"); it\nsays that it _can_. At a general level with \"--squash\", that seems to\nbe exactly correct. A \"--squash\" merge can create a new commit, or it\ncan fast-forward an existing commit if the situation allows. Based on\nthat, passing \"--ff\" doesn't seem misleading to me.\n\n> I think your idea of the 2 being distinctly separate makes\n> sense. Basically, --squash takes precedence and if the mechanism to\n> implement squash in certain scenarios (such as single commit) is\n> fast-forward merge, then that decision is made for the user and is no\n> longer something they can control.\n\nThe two _aren't_ distinctly separate, though. \"git merge --squash\n--ff-only\" has very different semantics to \"git merge --squash --ff\",\nin that it will only create a new squashed commit (or fast-forward a\nsingle commit) if the incoming commit(s) are fast-forward from the\ntarget. So there _is_ a setting for the fast-forward mode (given\n\"--ff\", \"--ff-only\", and \"--no-ff\" are a tri-state switch, and\ntherefore comprise a single setting) that does impact squashing.\n"},{"id":"336013","messageId":"1515183976.21764.114.camel@mad-scientist.net","threadId":"47545","inReplyTo":"CAGyf7-FHyO9pkEFFguea+B+VMTodF=mg8wJNedvjYdL7e7ORqQ@mail.gmail.com","subject":"Re: Can't squash merge with merge.ff set to false","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2018-01-05T20:26:16Z","receivedAt":"2018-01-05T21:22:06Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:\n> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey wrote:\n> > Not sure if this is intended or a bug, but with the following\n> > configuration:\n> > \n> > $ git config --global merge.ff false\n> > \n> > I am not able to merge my topic branch into master with squash\n> > option:\n> > \n> > $ git checkout master\n> > $ git merge --squash topic\n> > fatal: You cannot combine --squash with --no-ff.\n> > \n> > I'm not sure why a non-fast-forward merge would prevent a squash\n> > merge, since by its very nature a squashed merge is not a fast\n> > forward merge (or maybe it is if you only have one commit).\n\nHah! I was just thinking of checking the latest Git RC I built\nyesterday to see if this pet peeve of mine has been fixed yet. I guess\nnot!\n\n> The easiest way to move forward is probably to pass \"--ff\" on the\n> command line to override the config, when you're using \"--squash\".\n\nThat's what we always have to do. Very annoying; we use squash-merge\nextensively but also want to require ff merge by default.\n\n> As for why the two aren't allowed together, my assumption would be\n> because if you're only squashing a single commit \"--squash\" and that\n> commit is fast-forward from the target, a new commit is not created\n> and instead the target branch is fast-forwarded. With \"--no-ff\", it's\n> questionable what \"--squash\" should do in that case. Fast-forward\n> anyway? Rewrite the commit simply to get new committer details and\n> SHA-1?\n\nIf it only failed when you were squash-merging a single commit that was\nalso fast-forwardable, I guess that would be one thing. But even if I\nhave multiple commits and I want to squash-merge them, which clearly is\na separate operation giving different results, I get this error.\n\nI don't think Git should try to be clever here (if that's what it's\ndoing--I always assumed it was just a missing configuration case in the\nerror check). If I asked for a squash-merge then Git should give me a\nsquash merge.\n\nSo in answer to your question, --squash should give me a squash merge\nand the setting of --ff / --no-ff should be completely ignored, as it's\nirrelevant.\n\nMy $0.02.\n"},{"id":"336019","messageId":"CAHd499BfQiDen6PZFhEeB7-B64PeeQcCWNVze6fONsDGO=YHog@mail.gmail.com","threadId":"47545","inReplyTo":"CAGyf7-E-7KUCAM8SeG-2powp2XN+H=16VG-6XBmj1wUT9tjVcw@mail.gmail.com","subject":"Re: Can't squash merge with merge.ff set to false","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2018-01-05T21:44:19Z","receivedAt":"2018-01-05T21:44:25Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner wrote:\n> The two _aren't_ distinctly separate, though. \"git merge --squash\n> --ff-only\" has very different semantics to \"git merge --squash --ff\",\n> in that it will only create a new squashed commit (or fast-forward a\n> single commit) if the incoming commit(s) are fast-forward from the\n> target. So there _is_ a setting for the fast-forward mode (given\n> \"--ff\", \"--ff-only\", and \"--no-ff\" are a tri-state switch, and\n> therefore comprise a single setting) that does impact squashing.\n\nThat feels really contrived to me though. For example, when I'm asking\nto squash I don't really care about fast forward in that case.\nSquashing means I'm expecting a possibly completely new commit with my\ncollective changes. If I only had one commit on my branch, likely I'd\nbe aware of that, and would do a fast forward merge or something. I\nthink the difference here is mind set. And maybe this is just me, but\nthe mentality when I choose --squash means I want nothing to do with\nfast-foward. I don't care about it affecting the operation. If a\nfast-foward happens to be the end result, I still don't care. Git made\nthat decision for me. And all I want is the end result: A single\ncommit.\n"},{"id":"336033","messageId":"20180106001131.GA54183@aiede.mtv.corp.google.com","threadId":"47545","inReplyTo":"CAHd499C=3Y-ykgYZhSJzk=e-Pi6BUFeN8C89krd5T7T5fRB91g@mail.gmail.com","subject":"Re: Can't squash merge with merge.ff set to false","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-01-06T00:11:31Z","receivedAt":"2018-01-06T00:11:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRobert Dailey wrote:\n\n> Not sure if this is intended or a bug, but with the following configuration:\n>\n> $ git config --global merge.ff false\n>\n> I am not able to merge my topic branch into master with squash option:\n>\n> $ git checkout master\n> $ git merge --squash topic\n> fatal: You cannot combine --squash with --no-ff.\n\nI see two issues here:\n\n 1. The check and error message really only make sense when you passed\n --no-ff directly, not implicitly using config. The problem you\n are running into was presumably introduced when merge.ff was added\n in v1.7.6-rc0~67^2~1 (2011-05-06).\n\n 2. Whether it comes from an alias or config, --no-ff and --squash are\n not fundamentally incompatible. --no-ff says not to do something\n and --squash says to do a different thing, so --squash should win.\n\nSo I suspect that making --squash override --no-ff would be a\nreasonable behavior.\n\nCare to write a patch?\n\nThanks,\nJonathan\n"}]}